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ABSTRACT 


This  thesis  formalizes  the  notions:  problem,  mechanism  and  solution,  and 
shows  how  such  a formalization  is  useful  in  describing  problems  and  proving 
the  correctness  of  solutions  to  them  in  computational  systems. 

Mechanisms  are  formally  defined  as  mappings  (layers)  between  two 
computational  systems.  They  provide  natural  models  for  protection, 
synchronization,  and  sequential  and  parallel  control  mechanisms.  Certain 
algebraic  properties  of  mechanisms  are  discussed;  these  correspond  to 
properties  one  would  ordinarily  consider  in  studying  the  mechanisms  listed 
above. 

We  consider  those  prob'ems  in  compu*. ationai  systems  that  may  be  solved 
either  by  adding  a mechanism  to  a system  or  by  imposing  a constraint  on  the 
states  in  which  the  system  is  initially  permitted  to  operate.  We  find  that 
many  such  problems  can  be  described  as  behavioral  problems,  constraints  on 
the  behavior  of  a system.  These  problems  may  be  described  in  a manner  that 
is  independent  of  the  particular  system.  A variety  of  important  protection 
problems  are  defined  in  this  way. 

We  develop  a formal  methodology  for  solving  problems  in  systems  with 
multiple  mechanisms.  We  use  it  in  developing  a number  of  solutions  to  a 
particular  protection  problem,  which  we  solve  by  constraining  both  a 
protection  mechanism  (determining  acceptable  initial  protection 
conf  igurat  ions)  and  a control  mechanism  (specifying  properties  that  must  be 
satisfied  by  programs  which  are  to  be  executed  by  certain  users). 


Finally  the  thesis  develops  a variety  of  constructs  for  specifying 
behavioral  problems  and  discusses  considerat ions  for  analyzing,  comparing 
and  measuring  solutions  to  them. 
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A NOTE  ON  NOTATION 

Throughout  this  thesis,  uie  have 
universal  quantifiers  in  logical 
might  be  improved.  For  example, 
write 


taken  the  liberty  of  removing 
formulae,  whenever  readability 
in  definition  2-12,  we 
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(Vo’)  ( <PM (a*)  d (VH’M  f(TM<o’,H’>)  ) ) 
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Chapter  1 - Introduction 


Section  1.1  Qvervieu 


When  we  interact  with  a complex  system,  be  it  a human  system  or  a 
computing  system,  we  inevitably  find  some  of  its  behavior  acceptable  and 
some  unacceptable.  Just  as  inevitably,  we  tend  to  do  what  we  can  to  bring 
about  acceptable  behavior  and  prevent  unacceptable  behavior.  Such  problem 
solving  is  the  focus  of  this  thesis. 

If  a problem  is  complex  enough  or  important  enough,  ue  create  mechanisms 
to  help  us  solve  the  problem.  Protection  mechanisms,  for  example,  arose 
from  a need  to  solve  certain  protection  problems,  such  as  preventing  those 
(unacceptable)  behaviors  where  one  user  might  access  another  user’s  private 
data. 

One  finds  many  sorts  of  mechanisms  in  computational  systems.  They 
include  protection  mechanisms,  synchronization  mechanisms,  high  level 

language  mechanisms  and  scheduling  mechanisms.  These  mechanisms  have 
certain  common  traits.  They  interpose  a layer  between  a base  system  and  a 
system  as  provided  to  a user.  They  enhance,  alter  and  modify  the  operations 
available  in  the  base  system,  sometimes  hiding  base  level  operations, 
sometimes  making  new  operations  available. 

In  this  thesis,  we  will  present  formal  definitions  for  the  terms  prob  I em. 
mechani  sm  and  sol  ut  ion.  Ue  will  demonstrate  how  this  formalism  may  be  used 
in  describing  problems  in  computational  systems,  developing  solutions  for 
them,  and  proving  their  correctness. 


This  thesis  focuses  primarily  on  protection  problems  (also  called  security 
policies,  as  in  [Jones  & Uulf  74]).  While  many  protection  problems  have 
been  described  in  the  literature  (for  example,  the  Mutual  Suspicion  Problem 
[Schroeder  72],  Safety  Problems  [Harrison,  Ruzzo  & Ullman  75]  and  the 
Confinement  Problem  [Lampson  73]),  no  general  theory  of  protection  problems, 
no  formal  language  for  their  specification,  and  no  set  of  proof  techniques 
has  yet  evolved.  It  is  hoped  that  this  thesis  will  provide  a framework  for 
such  developments. 
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It  is  important  that  research  in  protection  move  in  such  a direction. 
The  variety  and  quantity  of  information  stored  in  computational  systems 
continues  to  increase,  and  it  is  becoming  increasingly  more  important  for 
users  to  be  able  to  exercise  finer  and  finer  control  over  the  use  of  that 
information.  Users  must  be  able  to  formally  specify,  in  as  elegant  a 
language  as  possible,  their  protection  requirements.  Further,  they  must  be 
able  to  determine  when  and  how  those  requirements  may  be  met.  In  effect, 
this  requires  a formal  theory  of  protection,  for  which  the  ideas  In  thir 
thesis  form  a base. 


Section  1.2  Synchronization  Problems  and  Mechanisms 


Ue  will  show  that  there  are  many  parallels  between  synchronization  and 
protection  problems  and  the  mechanisms  designed  to  solve  them. 
Formalization  in  synchronization  has  proceeded  more  rapidly  and  more 
generally  than  formalization  of  protection.  In  this  section,  we  will  survey 
research  in  synchronizat  ion,  paying  special  attention  to  the  development  of 
specification  and  proof  techniques  in  order  to  determine  whether  some  of 
these  might  be  important  for,  or  applicable  to,  protection  as  well. 

[ [Hewitt  74]  contrasts  synchronization  and  protection  problems 
and  mechanisms,  in  terms  of  a universal  "actor"  formalism.  That 
work,  especially  the  notion  of  behavioral  specification  as  pursued  in 
[Greif  & Hewitt  75]  and  CGreif  753,  has  influenced  many  of  the  ideas 
discussed  and  formalized  in  this  thesis.  ] 

One  of  the  earliest  synchronization  problems,  to  be  stated  was  the  Mutua I 
Exc  I us  ion  Problem,  discussed  in  [Dijkstra  B8a3 . Uhen  multiple  users  share 
access  to  an  object  (e.g.  processor,  memory,  file,  etc.).,  maintaining  the 
integrity  of  the  object  may  require  that  operations  on  it  do  not  overlap. 
To  prevent  this  overlap,  a process  requesting  use  of  the  object  must  wait 
until  that  object  is  not  being  used  by  any  other  process.  Dijkstra  showed 
how  his  mechanism,  which  introduced  the  operations  P and  V,  could  be  used  to 
solve  the  Mutual  Exclusion  Problem,  and  could  in  principle,  be  used  to  solve 
any  synchronization  problem  at  all. 


However,  PV  proved  inadequate  (or  at  least  inconvenient)  for  solving 
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certain  generalizations  of  the  Mutual  Exclusion  Problem.  The  PVmultiple 
mechanism  [Patil  71]  permitted  a user  to  gain  exclusive  access  to  a set  of 
objects  all  at  once.  A process  making  such  a request  would  be  blocked  until 
it  could  be  granted  access  to  all  objects  requested.  The  PVchunk  mechanism 
[Vantilborgh  & Lamsweerde  721  was  developed  for  those  situations  in  which 
resources  are  represented  as  collections  of  objects  (such  as  pages  of  memory 
or  tracks  of  a disk),  and  processes  request  a chunk  (some  number)  of  these 
at  a time.  Using  the  PVchunk  mechanism,  a process  would  block  until  the  the 
process  could  be  granted  exclusive  access  to  the  exact  number  of  objects 
requested. 

Even  these  mechanisms  proved  to  be  inadequate  for  solving  more  complex 
problems.  In  Reader-UIr  i ter  problems  (Courtois,  Heymans  & Parnas  71],  a 
distinction  is  made  between  processes  that  read  from  and  those  that  write  to 
an  object.  Multiple  rea  lers  may  access  an  object  simultaneously.  However, 
writers  must  be  given  exclusive  access  to  the  object  and  must  not  overlap 
with  any  reader.  Versions  of  the  problem  abound,  differing  in  the  way  one 
assigns  priorities  to  the  readers  and  writers.  PV  mechanisms  do  not  admit 
especially  elegant  solutions  to  Reader-Ur i ter  problems.  Other  mechanisms, 
subsequently  introduced  are  better  in  that  regard,  notably  the  up/down 
mechanism  [Uodon  72]. 


The  mechanisms  described  above  define  new  operations  (P  and  V,  etc.), 
which  could  be  misused  by  users.  Monitors  (Hoare  74]  and  Regions 
[Hansen  73]  also  introduce  new  sets  of  operations  but  embed  them  in  a 
syntactic  structure  to  prevent  misuse.  (The  operations  for  monitors  are: 
enter  monitor,  wait,  signal  and  exit  monitor.  Brinch  Hansen’s  operations 
permit  a process  to  block  until  an  arbitrary  condition  is  satisfied.)  The 
syntactic  constraints  provide  an  important  function.  By  imposing  a 
structure  on  the  solution  to  a synchronization  problem,  one  might  reasonably 
consider  proving  that  it  is  correct. 

Jf  course,  a proof  that  a solution  to  a given  problem  is  correct  requires 
a ormai  specification  of  the  problem.  Initially,  specifications  for 
synchronization  problems  were  given  informally,  much  like  our  description  of 
the  problems  above.  The  imprecision  of  informal  specification  inevitably  led 
to  controversy,  in  particular  regarding  the  correctness  of  the  PV  solution 
to  the  second  Reader-Ur i ter  problem  as  presented  in  (Courtois,  Heymans  & 
Parnas  71 ] . 


Problems,  Mechanisms  & Solutions  ( 1.2  ) page  A 

In  order  to  discuss  the  formal  specification  of  a problem,  we  must  first 
describe  the  effect  of  a mechanism  upon  a system.  Consider  the  system  that 
happens  to  contain  the  operations,  reqlp.r),  use(p,r)  and  free(p,r). 
These  operations  define  operations  executed  by  process  p that  request,  use 
and  free  object  r.  The  sequence  of  operations 

req(l,r)  use(l,r)  freed, r)  req(2,r)  use(2,r)  free!2,r) 

describes  the  behavior  of  the  system  where  process  1 first  requests,  uses 
and  frees  r,  followed  by  request,  use  and  freeing  of  r by  process  2.  The 
sequence 

req(l.r)  req(2,r)  usell.r)  use(2,r)  freed, r)  free(2,r) 

describes  a situation  in  which  process  2 uses  r before  r has  been  freed  by 
process  1.  If  the  system  contains  no  synchronization  mechanism,  this 
sequence  is  perfectly  legitimate.  But  if  the  system  contains  a mechanism 
designed  to  solve  the  Mutual  Exclusion  problem,  this  sequence  is  prevented 
from  occuring.  When  process  2 requests  access  to  r,  it  will  block  unt'l  r 
has  been  freed  by  process  1. 

I n general  . mechani sms  prevent  the  occurrence  of  certain  sequences  of 
operations.  A synchronization  problem  can  then  be  specified  as  set  of 
acceptabl e sequences  (for  example,  those  in  which  no  process  uses  an  object 
that  is  in  use  by  another  process).  A mechanism  can  be  used  to  solve  a 
synchronization  problem  if  it  permits  just  those  sequences  uhich  are 
acceptable.  Since  we  cannot  expect  to  explicitly  list  those  sequences  which 
are  acceptable  or  unacceptable,  we  next  consider  ways  in  which  the  set  of 
acceptable  sequences  might  be  specified. 

The  specification  techniques  closest  to  explicitly  listing  the  set  of 
acceptable  sequences  are  those  which  are  modifications  of  the  regular 
expressions  of  formal  language  theory  [.Hopcroft  & Uliman  G9J . These  include 
event  expressions  [Riddle  73],  path  expressions  [Campbell  4 Habermann  751, 
and  the  recent  work  reported  in  [Schneider  7GI . 

In  [Lipton  731,  a problem  is  specified  as  a "solution"  defined  for  a given 
mechanism.  For  example,  Lipton  defines  one  set  of  acceptable  sequences  to 
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be  just  those  permitted  by  the  up/down  "solution"  to  the  2nd  Reader-Ur i ter 
problem  as  described  in  (Uodon  723.  Lipton  then  goes  on  to  show  that  this 


of 

up/down. 

is 

specified  as 

an 

is, 

, a predicate 

on 

f 

any  sequence 

of 

operations.  The  state  contains  pseudo-variables  that  are  used  to  to  encode 
salient  characteristics  of  the  previous  behavior,  such  as  the  difference 
between  the  number  of  requests  and  frees  executed. 


To  show  that  a particular  mechanism  can  be  used  to  solve  a 

synchronization  problem  specified  by  an  invariant,  one  must  show  that  the 
mecnanism  blocks  a process  as  long  as  subsequent  execution  of  the  process 
would  result  in  a state  not  satisfying  the  predicate.  Ue  will  find  that 
invariants  are  useful  for  specifying  protection  problems  as  well  as 
synchronization  problems.  Ue  will  refer  to  problems  defined  in  this  way  as 
static  problems. 

tHabermann  723  first  specified  synchronization  problems  as  invariants. 
However,  he  only  considered  those  invariants  which  could  be  expressed  in 
terms  of  the  number  of  times  an  object  has  been  requested  or  freed. 
Counting  constructs  alone  are  not  sufficient  for  specifying  many 
synchronization  problems,  particularly  those  involving  priorities. 
[Belpaire  753  has  suggested  additional  constructs  that  may  be  useful  in 
developing  a special  purpose  specification  language  for  synchroni zat ion. 

CGreif  753  argues  against  taking  the  "invariant"  route.  She  specifies 
the  set  of  acceptable  sequences  by  imposing  ordering  constraints.  For 
example  (using  prose  in  place  of  her  notation):  If  operatton-1 

(e.g.  req(l.r)  ) precedes  operation-?  I req(2,r)  ) then  operaticn-3 
( freed, r)  3 must  precede  operation-4  ( use(2,r)  3. 


The  danger  of  invariant  specifications  is  that  by  adding  pseudo-var iables, 
whose  value  may  be  altered  cs  execution  proceeds,  one  comes  perilously  close 
to  defining  specification:.  in  terms  of  an  implementation  (the 
pseudo- var i ab I es  becoming  part  of  the  actual  state  of  the  mechanism  used  to 
implement  the  specification).  It  should  be  noted  that  there  are  those, 
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be  just  those  permitted  by  the  up/down  "solution"  to  the  2nd  Reader-Ur  i ter 
problem  as  described  in  [Uodon  723.  Lipton  then  goes  on  to  show  that  this 
set  of  sequences  cannot  be  generated  by  using  PV  instead  of  up/down. 

In  [Robinson  & Holt  74],  a synchronization  problem  is  specified  as  an 
invariant  property  or  the  state  of  the  system,  that  is,  a predicate  on 
states  that  must  remain  satisfied  over  execution  of  any  sequence  of 
operations.  The  state  contains  pseudo-variables  that  are  used  to  to  encode 
salient  character) sties  of  the  previous  behavior,  such  as  the  difference 

between  the  number  of  requests  and  frees  executed. 

To  show  that  a particular  mechanism  can  be  used  to  solve  a 

synchronization  prob'sm  specified  by  an  invariant,  one  must  show  that  the 
mechanism  blocks  a process  as  long  as  subsequent  execution  of  the  process 
would  result  in  a state  not  satisfying  the  predicate.  Ue  will  find  that 
invariants  are  useful  for  specifying  protection  problems  as  well  as 

synchronization  problems.  Ue  will  refer  to  problems  defined  in  this  way  as 
static  problems. 

[Habermann  721  first  specified  synchronization  problems  as  invariants. 
However,  he  only  considered  those  invariants  which  could  be  expressed  in 

terms  of  the  number  of  times  an  object  has  been  requested  or  freed. 
Counting  constructs  alone  are  not  sufficient  for  specifying  many 

synchr oni za t i on  problems,  particularly  those  involving  priorities. 

[Belpaire  751  has  suggested  additional  constructs  that  may  be  useful  in 

developing  a special  purpose  specification  language  for  synchronization. 

[Greif  75]  argues  against  taking  the  "invariant"  route.  She  specifies 

the  set  of  acceptable  sequences  by  imposing  ordering  constraints.  For 
example  (using  prose  in  place  of  her  notation):  If  operation-1 

(e.g.  req(l,r)  ) precedes  operation-2  ( req(2,r)  ) then  operation-3 

( freed,  r)  ) must  precede  operation-4  { use(2,r)  ). 

The  danger  of  invariant  specifications  is  that  by  adding  pseudo-variables, 
whose  value  may  be  altered  as  execution  proceeds,  one  comes  perilously  close 
to  defining  spec i f ica t ions  in  terms  of  an  implementation  (the 

pseudo-var i ab I es  becoming  part  of  the  actual  state  of  the  mechanism  used  to 
implement  the  specification).  It  should  be  noted  that  there  are  those, 
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especially  [Griffiths  74],  who  do  not  find  this  sort  of  specification 
dangerous.  Greif  argues  (I  think  correctly)  that  behavioral  specifications 
(such  as  hers,  and  those  based  on  regular  expressions)  have  the  potential 
for  describing  problems  in  a manner  closest  to  our  intuitive  understanding  of 
them.  t This  potential  has  not  yet  been  fully  realized,  for  each  of  the 

behavioral  specification  languages  referenced  treats  many  situations 

inelegantly.  ] Problems  described  in  terms  of  behavioral  specifications  are 
termed  behavioral  problems,  in  contrast  to  static  problems  which  are 
described  in  terms  of  invariants. 


Sect  ion  1.3 Protection  Problems  and  Mechanisms 


In  this  section,  we  will  survey  the  developments  in  protection  problems 
and  protection  mechanisms,  insofar  as  there  are  parallels  with 
synchronization.  l*le  argue  that  the  same  formal  treatment  already  provided 
for  synchronization,  rigorous  definitions  of  problem,  mechanism,  and 
solution,  techniques  for  proving  the  correctness  of  solutions,  and 
specification  languages  for  problems,  can  be  usefully  applied  to  the  study 
of  protection.  All  but  the  last  are  dealt  with  in  this  thesis. 

Ue  start  by  discussing  some  of  the  early  protection  mechanisms  and  the 
problems  they  uere  designed  to  solve.  Two  of  these,  the  Access  problem  and 
the  Hidden  Facilities  problem  will  be  discussed  more  formally  in  sections 
4.2  and  5.2  respectively. 

The  earliest  protection  mechanisms  were  designed  to  solve  Access 
Problems.  For  example,  the  creator  of  lor  some  user  reponsible  for)  an 
object  (e.g.  a file)  may  wish  to  prevent  certain  other  users  (or  classes  of 
users)  from  reading  or  writing  the  object.  CTSS  [Crisman  65]  was  one  of  the 
early  systems  that  provided  a mechanism  that  could  be  used  to  solve  the 
problem.  It  associated  an  "authority  list"  with  each  file,  a list  of  names 
specifying  those  users  authorized  to  access  the  file,  and  the  type  of  access 
permitted  for  each  of  these.  The  protection  mechanism  prevented  execution 
of  any  operation  that  would  allow  ar,  unauthorized  user  to  access  a file  in  a 
way  not  permitted  by  the  authority  list. 


The  Propr ietaru  Program  Problem  can  be  solved  using  the  same  sort  of 
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mechanism.  A user  may  wish  to  make  a proprietary  program  available  to  other 
users  as  long  as  they  are  unable  to  read  the  program  (they  may  only  execute 
it).  The  authority  list  for  the  file  containing  the  program  can  contain  an 
indication  that  other  users  are  permitted  to  execute  the  file,  though  not  to 
read  or  write  it. 

The  introduction  of  the  Multics  protection  mechanism  (Organick  72, 
Schroeder  <S  Saltzer  72,  Saltzer  74]  permitted  the  solution  of  a number  of 
additional  problems,  the  Hidden  Facilities  Problem,  the  Protected  Subsystem 
Problem  and  the  Trojan  Horse  Problem.  He  will  briefly  discuss  each  one 
below. 

Many  facilities  (compilers,  devices,  etc.)  may  ordinarily  be  available  to 
users  of  a computing  utility.  The  Hi dden  Facilities  Prob I em  requires  that 
certain  users  (e.g.  students  in  programming  courses)  be  denied  access  to 
certain  of  these  facilities  (except  perhaps  through  the  controlled  use  of 
other  faci I i ties)  . 

The  Protected  Subsustem  Problem  is  an  amalgam  of  the  Proprietary  Program 
Problem  and  the  Hidden  Facilities  Problem.  A user  is  to  be  permitted  to 
access  an  object,  but  not  directly.  Instead,  certain  programs  are  to  made 
available  to  the  user,  which  may  be  executed  (but  neither  read  nor  written). 
Only  these  programs  are  to  be  able  to  access  the  object  directly.  The 
collection  of  programs  (and  the  objects  they  maintain)  are  called  a 
Protected  Subsystem. 

As  described  above,  the  Proprietary  Program  problem  can  be  seen  as 
character iziny  a situation  in  which  the  owner  of  a program  does  not  trust 
users  of  the  program.  The  Troian  Horse  Prob  I em  is  concerned  with  the 

reverse  situation.  A user  wishes  to  execute  a borrowed  program,  but  wants 
to  guarantee  that  when  executing,  the  program  will  not  (maliciously  or 
accidentally)  access  or  damage  files  owned  by  the  user  that  the  program  has 
no  need  to  access.  (The  problem  is  called  the  Trojan  Horse  problem  since, 
lurking  within  the  depths  of  an  elegantly  crafted  program  made  available  by 
another  user,  may  be  a collection  of  code  that  could  potentially  destroy  the 
user  (or  at  least  her  files)). 

It  is  possible  that  neither  the  owner  nor  the  borrower  of  a program  trust 
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one  another.  This  problem,  termed  the  Mutual  Suspicion  Problem 
CSchroeder  72],  cannot  be  solved  in  Multics,  though  Schroeder  shows  how 
Multics  may  be  modified  to  support  a solution.  This  example  illustrates  a 
point  to  which  we  will  return  in  discussing  negotiation  below.  A mechanism 
(Multics  rings)  that  supports  solutions  to  some  set  of  problems  (Protected 
Subsystem,  Trojan  Horse)  may  not  be  able  to  support  solution  to  combinations 
of  these  problems  (Mutual  Suspicion). 

He  have  not  intended  to  be  complete  in  our  discussion  of  either 
protection  problems  or  protection  mechanisms.  Descriptions  of  additional 
problems  and  mechanisms  used  to  solve  them  are  described  in  (Dennis  & Van 
Horn  66]  , (Lampson  71],  (Gray  72],  (Atwood  72],  CNc  edham  721,  (Graham  & 
Denning  72],  (Jones  73],  (Cosserat  74],  [Jones  & Uulf  74],  [Redell  74], 
[Redell  & Fabry  74]  and  (Cohen  & Jefferson  75].  This  list  does  not  include 
a class  of  problems  we  call  Information  Problems;  we  will  discuss  them 
separately  in  section  1,6. 


While  at  least  os  many  protection  problems  have  been  described  in  the 
literature  as  synchronization  problems,  no  specification  languages  for 
protection  have  yet  appeared,  and  not  one  of  the  protection  problems 
discussed  above  has  yet  been  specified  in  a suitably  formal  manner. 
However,  we  can  character i ze  a protection  problem  in  the  same  way  that  we 
character  ized  a synchronization  problem  - as  a set  of  acceptabi  e sequences 
of  operat  ions.  For  example,  consider  the  protection  problem:  guarantee  that 
Cohen  cannot  write  the  Salary  file.  The  set  of  acceptable  sequences  are 
those  that  contain  no  operation  whose  effect  is  that  Cohen  writes  the  Salary 
file. 

The  reasons  why  an  operation  may  not  appear  in  a sequence  are  different 
for  synchronization  problems  and  protection  problems.  In  synchronization, 
the  fact  that  an  operation  (e.g.  use(2,r)  ) cannot  appear  signifies  that  its 
executor  must  be  blocked  (e.g.  another  process  is  currently  using  the  same 
resource).  In  protection  problems,  an  ope’-^tion  (e.g.  wri  te  (Cohen,  Sa  i ary)  ) 
may  not  be  permitted  because  otherwise  in  access  violation  may  occur  (e.g. 
if  Cohen  '19  not  to  be  permitted  to  write  the  Salary  file).  H.ien  an 
operation  is  not  permitted  in  a protection  system,  the  process  generally 
does  not  block.  In  early  systems  it  might  have  been  aborted;  in  current 
systems,  an  error  may  be  signalled.  t This  does  not  imply  that 
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synchronization  should  always  imply  blocking  - if  an  executor  cannot  gain 
access  to  a resource,  one  might  want  to  allow  the  user  the  option  to  use 
another  resource  instead.  Similarly,  when  an  access  violation  occurs,  one 
might  want  to  block  the  offending  executor  until  it  is  granted  the 

appropriate  access  rights.  1 In  any  case,  both  synchronization  and 
protection  problems  can  be  stated  in  terms  of  acceptable  sequences  of 
operations,  no  matter  what  semantic  action  is  intended  when  unacceptable 

behaviors  are  attempted. 

Given  that  we  want  to  formally  describe  a protection  problem  as  a set  of 
acceptable  sequences,  we  find  we  are  faced  with  the  same  choice  as  the 

specifier  of  synchronization  problems.  We  will  show  in  sections  4.2  and 
5.2  that  certain  protection  problems  may  be  specified  most  generally  (i.e. 
without  regard  to  the  particular  protection  mechanism  used)  as  behavioral 
problems.  Once  the  mechanism  is  specified,  the  problem  may  often  be 

restated  as  a static  problem,  that  is,  as  a property  of  the  state  of  the 

entire  system  (including  the  mechanism)  that  is  to  remain  invariant.  While 

the  behavioral  specification  is  more  general,  it  is  easier  to  demonstrate 
invariance  of  the  static  specification  than  satisfaction  of  the  behavioral 

speci f i cat  ion. 

Some  protection  problems  have  been  formalized,  but  the  specifications 
have  all  made  some  sort  of  assumption  about  the  system  in  which  the  problem 
is  to  be  solved.  In  [Price  73),  a proof  is  provided  of  the 

"Ch  i nese-Amer  i can  War  Games  Theorem"  - that  is,  that  two  processes  may 

execute  concurrently  yet  be  guaranteed  to  not  interact.  The  statement  of 
the  problem  is  only  valid  though,  for  the  particular  virtual  memory 
mechanism  that  Price  studies. 

In  [Harrison,  Ruzzo  & Ullman  75],  safety  problems  are  discussed,  those 
guaranteeing  that  no  user  can  ever  gain  some  particular  kind  of  access  to 
any  object.  These  problems  are  equivalent  to  those  of  the  form?  Guarantee 
that  user  x cannot  gain  q access  to  object  (3.  Of  course,  these  problem  are 
very  strongly  mechanism  dependent.  They  are  only  relevant  for  those 
protection  mechanisms  that  can  be  described  using  Lampson’s  access  matrix 
(Appendi x A) . 


[ The  access  matrix  describes  at  any  given  instant  who  may  access 
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what  in  which  way.  (The  rows  are  users,  the  columns  are  objects, 
and  each  entry  lists  the  ways  in  which  a user  may  access  an  object). 
When  a user  attempts  to  execute  an  operation,  the  mechanism  prevents 
execution  of  the  operation  if  it  uould  cause  an  access  to  be  made 
that  is  not  permitted  by  the  appropriate  entry  in  the  matrix. 
Access  matrix  systems  also  provide  operations  that  permit  across  tn 
be  shared  with  or  revoked  from  another  user;  these  operations  change 
the  configuration  of  the  matrix.  ) 

In  [Jones  73),  a number  of  protection  problems  are  specified  and 

solutions  to  them  are  proven  correct.  This  thesis  extends  that  work  by 
providing  a formal  notation  that  permits  a formal  specification  of  problems 
i ndependent  I u of  the  mechanisms  (in  Jones'  case,  an  access-rights  mechanism) 
used  to  solve  them.  We  also  develop  a number  of  (straight forward)  proof 
techniques  that  permit  a rigourous  (and  potentially  mechanizabl e) 

demonstration  of  the  correctness  of  a solution. 

As  the  use  of  protection  in  systems  becomes  more  varied  and  more 

widespread,  we  will  come  to  understand,  better  than  we  do  now,  what 

protection  problems  are  important.  We  will  come  to  see  the  s*  ucture  of  the 
problems  we  want  to  solve,  and  from  that  understanding,  see  how  to  build  new 
mechanisms  to  help  solve  them.  For  example,  a paradigm  that  will  likely 
increase  in  importance  is  the  negotiation  paradigm.  Consider  a user  who 
builds  a protected  subsystem  for  object  r,  and  then  makes  this  subsystem 
available  to  another  user  in  such  a way  that  access  to  r mny  subsequently  be 
revoked  at  any  time.  The  other  user  then  expends  some  signif'cant  amount  of 
time  and  energy  predicated  on  her  continuing  ability  to  use  r.  She  wishes  a 
guarantee  that  her  access  to  r will  not  be  revoked  (or  at  least  not  for  a 
while).  This  pairing  of  problems  is  similar  to  that  encountered  in  the 
discussion  of  Mutual  Suspicion  above,  . but  may  lead  to  more  serious 
difficulties.  The  requirements  of  both  users  may  actually  conf I ict.  and 
some  sort  of  neqot i a t i on  mechanism  may  be  needed  to  determine  whether  or  not 
they  can  ever  be  mutually  satisfied.  The  HYDRA  system  (Cohen  & 
Jefferson  75)  (Levin  75)  does  include  some  mechanisms  that  permit 
negotiation,  however  these  are  far  from  general. 

One  might  imagine  that  protection  mechanisms  of  the  future  will  permit 
users  to  specify  (in  some  undetermined  language)  their  access  and  control 
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requirements.  Sucn  negotiation  mechanisms  should  be  able  to  detect 
conflicts  and  possibly  mediate  disputes.  [Rotenberg  733  has  discussed  the 
social  implications  of  such  mechanisms.  [Peuto  ?4l  has  compared  this 
feature  of  protection  with  the  legal  process  in  real  estate  law. 

A negotiation  mechanism  for  any  reasonably  complex  system  must  be 
incomplete.  There  are  conflicts  in  access  requirements  which  a negotiation 
mechanism  will  be  unable  to  detect,  much  less  mediate,  so  we  can  never 
expect  to  find  the  ultimate  mechanism.  Ue  do  expect  that  a variety  of 
interesting  mechanisms,  including  those  explicitly  designed  to  permit 
specifications  for  negotiation,  will  continue  to  be  developed.  A 
formalization  of  protection  problems  uill  help  us  evaluate  these  mechanisms, 
for  we  can  formally  determine  how  well  they  can  be  used  to  solve  important 
prob I ems. 


Section  1.4  Problems  and  Solutions 


In  this  section,  we  discuss  the  relationship  between  behavioral  and  static 
problems  and  discuss  two  different  classes  of  behavioral  problems, 
enforcement  problems  and  productive  problems,  Ue  show  how  problems  can  be 
solved  by  imposing  a constraint  on  a system  and/or  adding  a new  mechanism  to 
it.  This  notion  of  solution  gives  rise  to  a methodology  for  solving  problems 
that  is  especially  useful  for  systems  containing  multiple  mechanisms. 

He  have  described  problems  as  sets  of  acceptable  sequences  of  operations. 
However,  what  is  acceptable  may  depend  upon  the  state  of  the  system.  In  one 
state,  some  operation  may  have  the  effect  of  writing  into  the  Salary  file, 
while  in  another  state  the  operation  may  have  an  entirely  different  effect. 
If  we  want  to  prevent  the  Salary  file  from  being  written,  the  operation 
would  be  unacceptable  in  the  first  case,  acceptable  in  the  second  case. 

In  some  states  of  the  system,  al  I sequences  of  operations  may  be 
acceptable.  For  example,  in  a access  matrix  system,  it  may  be  possible  to 
find  some  initial  configuration  of  the  access  matrix  that  guaranteed  that 
Cohen  could  never  gain  write  access  to  the  Salary  file,  no  matter  what 
operations  might  subsequently  be  executed.  In  general,  we  might  solve  a 
problem  by  permitting  the  system  to  operate  only  in  states  in  which  all 
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sequences  of  operations  are  acceptable.  Ue  characterize  those  states  by  an 
ini t ial  constraint. 


Since  sequences  may  be  acceptable  in  some  states  ue 
will  find  it  convenient  to  call  the  pair  < state,  sequence  > a behavi or 
(since  the  initial  state  of  a system  and  the  sequence  of  operations  executed 
in  that  state  completely  specify  the  behavior  of  the  system).  An  acceptable 
behavior  is  one  in  which  the  sequence  is  acceptable  for  the  initial  state. 


A behavioral  problem  is  any  problem  that  can  characterized  in  terms  of  an 
acceptable  set  of  behaviors.  Ue  have  said  that  static  problems  are  those 
that  are  specified  as  a property  of  the  state  of  the  system.  However,  even 
static  problems  can  be  seen  as  a shorthand  for  a corresponding  behavioral 
problem.  An  acceptable  behavior  is  one  whose  execution  results  in  a state 
satisfying  the  specified  property.  The  guarantee  that  the  property  remains 
invariant  is  equivalent  to  the  guarantee  that  only  acceptable  behaviors  are 
to  be  permitted. 


Ue  have  assumed  thus  far  that  all  behavioral  problems  are  to  be  solved  by 
guaranteeing  that  only  acceptable  behaviors  are  to  be  permitted.  Ue  will 
find  below  that  productive  problems  are  defined  differently  in  terms  of  the 
set  of  acceptable  behaviors;  those  that  we  have  been  discussing,  we  call 
Enforcement  Prob I erns.  Ue  showed  above  how  an  enforcement  problem  (prevent 
Cohen  from  gaining  write  access  to  the  Salary  file)  could  be  solved  by 
imposing  an  initial  constraint  on  a system,  and  throughout  this  introduction 
we  have  noted  how  mechanisms  may  be  added  to  a system  to  solve  problems. 
Below,  we  present  three  examples  that  illustrate  how  these  approaches 
interact. 


— [ Impose  Constraint  ) — Suppose  that  we  wished  to  prevent 

Cohen  from  writing  the  Salary  file.  Given  a system  containing  an 
adequate  protection  mechanism,  one  might  try  to  find  an  initial 
constraint  on  the  states  (e.g.  a constraint  on  the  initial 
configurations  of  the  access  matrix)  that  guaranteed  that  Cohen 
could  never  gain  write  access  to  the  Salary  file. 


ft 


— C Add  Mechanism  ] — Next,  suppose  that  we  wished  to  solve  the 

same  problem  (preventing  Cohen  from  writing  the  Salary  file)  in  a 
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system  containing  no  protection  mechanism.  One  might  choose  to  add 
the  cheapest  mechanism  to  the  system  that  could  be  used  to  solve  the 
problem.  Instead  of  adding  an  access  matrix  system,  one  might  build 
a mechanism  that  inspected  each  operation  attempted.  If  execution 
of  the  operation  would  permit  Cohen  to  urite  the  Salary  file,  the 
mechanism  would  not  permit  execution  of  the  operation. 


— [ Impose  Constraint  & Add  Mechanism  1 — Finally,  suppose  that 

we  were  given  a system  that  contained  an  incomplete  access  matrix 
mechanism,  one  in  which  Cohen  might  circumvent  the  protection 
mechanism  by  executing  the  operation  " sneaky-wr i te" . One  might 
add  an  additional  mechanism  to  this  system  that  simply  prevented  all 
sneaky-write’s.  Of  course,  as  in  the  first  example,  to  prevent 

Cohen  from  writing  the  Salary  file  through  non-sneaky  operations,  we 
would  still  have  to  impose  an  initial  constraint  on  the  given  system 
that  prevented  Cohen  from  gaining  write  access  to  the  Salary  file. 


Enforcement  problems  are  solved  by  guaranteeing  that  no  unacceptable 
behaviors  are  permitted.  The  preceding  discussion  argues  that  this 
guarantee  can  be  met  either  by  initially  constraining  a system  or  by  adding 
some  mechanism  to  it.  Ue  imagine  that  one  might  like  to  avoid  adding 
mechanisms  when  possible,  and  that  when  mechanisms  mu-jt  be  added,  they 
should  be  as  simple  as  possible.  A methodology  for  solving  an  enforcement 
problem  might  then  be  described  as: 


1.  Find  an  initial  constraint  that  will  eliminate  as  many 
unacceptable  behaviors  as  possible  (hopefully  all  of  them). 


2.  If  any  unacceptable  behaviors  remain  to  be  prevented,  add  a 
mechanism  to  the  system  that  prev  r»s  them. 


In  practice,  we  may  not  be  given  the  option  of  adding  an  arbitrary 
mechanism  to  a system.  Some  fixed  mechanism  may  be  provided,  though  we 

imagine  we  can  vary  the  behaviors  prevented  by  the  mechanism  by  initializing 
it  in  different  ways.  Our  methodology  for  solving  a problem  then  becomes: 


1.  Find  an  initial  constraint  that  wil!  eliminate  as  many 
unacceptable  behaviors  as  possible. 


Problems,  flechanisms  & Solutions  ( 1.4  ) 


page  14 


2.  Initialize  the  mechanism  so  that  it  will  prevent  the  execution 
of  the  remaining  unacceptable  behaviors. 

In  effect,  this  latter  approach  provides  a means  of  dealing  with  systems 
that  include  multiple  mechanisms,  where  the  use  of  one  of  the  mechanisms  is 
to  be  preferred  (e.g.  for  reasons  of  simplicity  or  reliabifify).  Assume 
that  the  system  as  given  includes  just  the  preferred  mechanism,  but  not  the 
other  mechanisms.  If  an  initial  constraint  on  that  given  system  eliminates 
all  unacceptable  behavior,  then  the  remaining  mechanisms  need  not  be  used. 
At  worst,  they  will  be  used  sparingly.  We  apply  this  approach  in  section 
4.5  and  chapter  5. 


He  close  this  section  by  briefly  discussing  Productive  Problems.  We 
found  that  the  enforcement  problem  - Cohen  is  not  to  write  the  Salary  file  - 
might  be  solved  (in  an  access  matrix  system)  by  imposing  some  initial 
constraint  on  the  system.  Vet  at  system  initialization  time,  it  may  not  be 
clear  that  Cohen’s  access  will  need  to  be  restricted,  and  the  requisite 
initial  constraint  may  not  be  satisfied  when  the  problem  needs  to  be  6olved. 
As  a result,  the  Salary  file  manager  may  need  to  solve  the  following  problem 
instead:  Produce  a state  that  satisfies  the  requisite  constraint. 


That  productive  problem  may  be  described  in  terms  of  acceptable  behaviors 
those  whose  execution  results  in  a state  satisfying  the  requisite 
constraint.  However,  it  is  not  necessary  that  everu  behavior  executed  be 
acceptable  - only  that  for  any  of  a set  of  current  states,  there  be  at.  I east 
one  acceptable  behavior  that  the  Salary  file  manager  can  execute. 
Productive  problems,  like  enforcement  problems,  can  be  solved  by  an  initial 
constraint  and  a mechanism.  The  initial  constraint  defines  the  set  of 

"current  states"  from  which  an  acceptable  sequence  of  operations  can  be 
executed.  The  mechanism  can  be  used  to  represent  the  program  that  executes 
that  acceptable  sequence. 


\ 


\ 
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Sec  t i on  1.5 Mechanisms 

The  description  of  a mechanism  can  be  seen  as  analogous  to  that  of  a 
level  of  hierarchy  [Qijkstra  68b] , a virtual  machine  monitor  [Popek  & 
Goldberg  743  and  decomposition  of  a module  [Parnas  723  . Each  level  of  an 
hierarchy  provides  a set  of  operations  that  may  be  used  in  constructing  the 
level  above.  For  example,  a level  of  hierarchy  corresponding  to  a 
protection  mechanism  might  use  the  operation  "write",  supplying  the 
operation  "protected-wr i te"  to  the  level  above. 


In  [Robinson  75],  a level  is  formally  specified  in  terms  of  a mapping  from 
oner  at  i ons  defined  by  the  level  .to  programs  imp  I emented  in  terms  of. 
oper at  i ons  def  i ned  by  the  level  below.  Our  definition  of  mechanism  may  be 
considered  to  be  a dynamic  realization  of  such  a specification.  We  define  a 
mechanism  as  a mapping  from  a behavior  defined  at  one  level  to  a behav i or 
def i ned  at  the  I eve  I below. 


While  our  definition  of  mechanism  derives  in  large  part  from 

[Robinson  753,  the  idea  of  mapping  sequences  of  operations  to  sequences  of 
operations  is  adapted  from  CLipton  731.  Lipton's  real  izat  ions  map  sequences 
of  operations  provided  by  one  synchronization  mechanism  to  sequences  of 
operations  provided  by  another  synchronization  mechanism.  Lipton’s 
definition  of  a synchronization  mechanism  contributed  to  the  formulation  of 
what  we  call  Dec i s i on  Mechanisms,  a class  of  mechanisms  that  can  be  used  to 
model  both  protection  and  synchroni zat ion  mechanisms. 


Finally,  the  work  reported  in  [Jones  & Lipton  75]  has  strongly  influenced 
our  formal  approach  to  the  way  in  uhich  mechanisms  may  be  used  to  solve 
protection  problems.  The  mechanisms  defined  in  [Jones  & Lipton  75]  do  not 
map  behaviors  to  behaviors,  but  rather  programs  to  programs.  Given  a 
program  P,  M is  said  to  be  a mechanism  for  P if,  for  any  input,  M either 
outputs  the  same  value  as  P or  a distinguished  output,  a violation  notice. 
A violation  notice  results  if  execution  of  P on  the  input  would  violate  the 
requirements  of  some  given  protection  problem.  A mechanism  that  g.ves 
violation  notices  at  least  as  often  as  it  should  is  said  to  be  sound. 

Soundness  is  related  to  the  notion  we  call  enforcement.  Suppose  we 
specify  a constraint  on  the  behaviors  acceptable  in  a system  - those 
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behaviors  satisfying  the  constraint  define  the  "acceptable"  set  of 
behaviors.  If  a mechanism  prevents  the  occurrence  of  all  of  the 
unacceptable  behaviors  (analogous  to  sending  a violation  notice),  the 
mechanism  is  said  to  enforce  the  constraint  on  behavior.  Note  that  the 
mechanism  may  prevent  acceptable  behaviors  from  occurring  as  well.  If  the 
mechanism  only  prevents  the  occurrence  of  unacceptable  behaviors,  then  we 
say  that  it  induces  rather  than  enforces  the  constraint  on  behavior.  This 

is  analogous  to  what  Jones  & Lipton  call  a maximal  I u comp  I ete  mechanism. 


Jones  & Lipton  view  a mechanism  as  a transformation  of  a program  and 
evaluate  it  (e.g.  soundness  and  completeness)  on  the  basis  of  whether  the 
result  of  executing  the  program  reflects  a v'olation  of  protection.  We  view 
a mechanism  as  constraining  behavior  and  evaluate  mechanisms  more  generally 
on  the  basis  of  the  behaviors  they  permit. 


Sect  ion  l.G Information  Problems 


Information  problems  are  those  protection  problems  concerned  with 
preventing  the  transmission  of  information.  In  this  section,  we  briefly 
describe  these  problems  and  their  relation  to  the  material  in  this  thesis. 


Early  research  in  information  problems  was  prompted  by  military 
requirements.  Each  object  in  a military  system  is  classified  and  categorized 
according  to  the  information  it  contains.  The  Mi  I i taru  Secur  i tu  Prob  I em 
requires  that  no  information  be  transmitted  to  a user  whose  clearance  does 
not  permit  access  to  that  information.  The  Adept-50  system  IWeissman  631 
was  the  first  to  include  a mechanism  intended  to  solve  this  problem, 
however,  as  pointed  out  in  [Denning  76) . ^hat  mechanism  is  flawed. 


Variants  of  the  military  security  problem  have  been  described  by  a number 
of  researchers  and  various  theoretical  treatments  of  information 
transmission  have  recently  appeared,  notably  those  by  [Jones  & Lipton  75) 
and  [Denning  761 . None  of  these  formal  treatments  have  been  based  on  a 
description  of  acceptable  behavior,  nor  can  they  be  converted  to  such  a 
description  in  any  obvious  way.  [Cohen  76)  discusses  the  relationship  of 
these  approaches  to  a behavioral  approach. 
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Ue  will  suggest  that  information  problems  can  be  specified  as  enforcement 
problems,  however  we  show  that  such  specifications  must  inherently  be 
incomplete  and  incorrect,  by  showing  that  solutions  to  information  problems 
do  not  satisfy  certain  properties  that  must  hold  true  of  solutions  to 
enforcement  problems. 

In  effect,  we  show  that  the  initial  constraint  itself  partially  determines 
what  behaviors  are  judged  to  be  acceptable.  This  demonstration  suggests  a 
new  formal  approach  to  information  transmission  which  is  pursued  in  [Cohen 
761  . 


Sec t i on  1.7 Plan  of  the  Thesis 


Chapter  2 introduces  the  basic  definitions  of  a computational  system  and 
a mechanism.  We  define  formally  how  the  imposition  of  an  initial  constraint 
or  the  addition  of  a mechanism  may  enforce  or  induce  constraints  on  the 
behavior  of  a system. 


In  chapter  3,  we  discuss  decision  mechanisms,  a special  class  of 
mechanisms  that  can  be  used  to  model  protection  mechanisms,  sequential  and 
mu  I t i programmed  control  mechanisms,  and  synchronization  mechanisms.  An 
initial  constraint  of  a control  mechanism  is  shown  to  correspond  to 
specification  of  a program  or  a property  some  program  must  satisfy.  Ue  also 
show  how  a system  may  be  extended  with  pseudo-operations,  useful  for 
specifying  a problem  independently  of  the  specification  of  the  mechanism. 

In  chapter  4,  we  formally  define  behavioral  and  static  enforcement 
problems  and  show  how  behavioral  specifications  may  be  converted  to  static 
ones  given  a system  that  already  contains  a mechanism  appropriate  for 
solving  the  problem.  Ue  show  how  these  problems  may  be  solved  and  why  it 
may  not  be  particularly  important  to  find  maximal  solutions  to  them. 


Ue  develop  a formal  methodology  for  solving  enforcement  problems  and 
illustrate  its  use  in  a system  that  contains  both  a control  mechanism  and  a 
protection  mechanism.  Ue  find  it  useful  to  treat  the  mechanisms  as  if  they 
had  been  added  in  layers,  with  the  control  mechanism  added  to  a system 
already  presumed  to  include  the  protection  mechanism. 


w 
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In  chapter  5,  we  9tudy  3 solutions  to  an  enforcement  problem.  Ue  uant  to 
guarantee  that  a set  of  sensitive  objects  may  be  altered  only  by  certain 
verified  programs,  in  a system  (described  in  Appendix  A)  containing  a 
protection  mechanism.  Ue  abstractly  specify  the  problem  as  a behavioral 
problem  (independently  of  the  mechanism).  Ue  then  show  hou  to  state  the 
problem  as  a static  problem,  where  the  mechanism  is  assumed.  The  latter 
form  is  more  useful  for  proving  the  correctness  of  the  solutions.  Each  of 
the  3 solutions  both  constrain  the  protection  mechanism  included  in  the  given 
system  (restricting  the  initial  conf igurat i ons  of  the  access  matrix)  and  a 
control  mechanism  (dictating  certain  properties  of  verified  programs)  that 
must  be  added  to  it. 

In  chapter  G,  productive  problems  are  formally  defined,  and  the 
methodology  developed  for  solving  enforcement  problems  is  extended  to  them. 
Ue  discuss  in  grearter  detail  the  phenomena  described  in  section  1.4  - the 
fact  that  many  enforcement  problems  require  the  solution  of  a corresponding 
productive  problem  as  well.  Finally  we  consider  a formal  character ization  of 
the  requirement  that  some  user  be  able  to  produce  an  acceptable  behavior  in 
the  face  of  interference  from  other  users. 

In  chapter  7,  we  formally  define  a problem  as  a charac ter i st i c function 
of  its  solutions.  Such  a notation  is  shown  to  be  useful  for  evaluating, 
comparing,  and  specifying  properties  of  solutions.  Ue  show  that  solutions 
to  enforcement  problems  satisfy  two  important  properties,  a Conta i nnient 
Proper tu.  and  a Join  Proper tu.  neither  of  which  are  satisfied  by  information 
prob I ems. 

Chapter  8 summarizes  the  results  of  the  thesis  and  indicates  directions 
for  future  research  as  well  as  work  already  in  progress. 


F 
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Chanter  2 - Modelling  Computational  Systems 

"Ue  have  a definite  system,  we  name  its  parts,  and  we  adopt,  in 
many  cases,  a single  symbol  to  represent  each  name.  In  doing  thi9, 
forms  of  express  on  are  called  inevitably  out  of  the  need  for  them, 
and  the  proofs  of  theorems,  which  are  first  seen  to  be  little  more 
than  a relatively  informal  direction  of  attention  to  the  complete 
range  of  possibilities,  become  more  and  more  recognizably  indirect 
and  formal  as  we  proceed  from  our  original  conception... 

"The  discipline  of  mathematics  is  seen  to  be  a way,  powerful  in 
comparison  with  others,  of  revealing  our  internal  knowledge  of  the 
structure  of  the  world,  and  only  by  the  way  associated  with  our 
common  ability  to  reason  and  compute." 

G.  Spencer  Broun  "Laws  of  Form" 

Section  2.1  Introduction 

In  this  chapter  we  formally  define  a computat ional  system  in  terms  of 
states  and  operat i ons.  A state  is  comprised  of  uniquely  named  objects; 
operations  alter  the  state  by  changing  the  contents  of  these  objects  when 
executed.  Using  this  model,  we  formally  define  the  terms  executor,  hi storu 
and  behavior. 


A mechanism  may  be  thought  of  as  a layer  interposed  between  a given  base 
sus tern  and  a system  as  presented  to  a user,  an  augmented  sus tern.  The 
mechanism  transforms  operations  executed  by  the  user  in  the  augmented  system 
to  operations  executed  in  the  base  system.  A part  of  the  formal 
specification  of  a mechanism  describes  the  mapping  from  behaviors  in  the 
augmented  system  to  behaviors  in  the  base  system.  In  order  to  perform  this 
mapping,  the  mechanism  may  require  its  own  mechani sm  state,  distinct  from 
the  state  of  the  base  system.  The  mechanism  state  may  need  to  be 
initialized  to  perform  properly,  A specification  of  the  required 
initialization  completes  the  formal  specification  of  a mechanism. 


One  might  imagine  cases  where,  in  adding  a mechanism,  the  happy  hacker 
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might  be  tempted  to  change  (albeit  in  small  ways)  the  definition  of  the 
operations  of  the  underlying  base  system.  Ue  will  not  consider  such 
mechanisms  in  this  thesis  beyond  showing  that  they  correspond  to  a class  of 
mechanisms  that  are  not  homomorphic.  Homomorphism  is  but  one  of  a number  of 
algebraic  properties  of  mechanisms  that  we  will  di9CU99. 

The  behavior  of  a system  may  be  constrained  by  imposing  a constraint  on 
the  initial  state  of  the  system  or  by  adding  a mechanism  to  it.  Ue  conclude 
the  chapter  by  describing  how  mechanisms  and  initial  constraints  can  be  used 
to  induce  and  enforce  constraints  on  the  behavior  of  a system. 

Section  2.2  Computational  Systems 


2. 2. a Discrete  Serial  Free  Systems 

A Computational  System  is  a di  screte  ser i a I free  system.  Such  a system 
is  a pair  <Z,A>  where  1 if  ,:he  set  of  states  of  the  system  and  A is 
the  set  of  operations,  each  of  which  effects  a state  transition  when 

executed.  A system  is  di  screte  in  the  sense  that  the  state  does  not  change 

continually:  execution  of  on  operation  causes  a discrete  state  transition. 

A system  is  ser  ial  in  that  there  is  no  concurrent  execution  of 
operations.  This  does  not  preclude  use  of  this  model  in  studying  systems 
with  concurrency.  It  is  only  necessary  to  assume  that  when  operations 
execute  concurrently,  the  result  is  the  same  no  matter  how  their  execution 
is  interleaved  (see  section  2.4). 

A system  is  free  in  that  the  choice  of  the  operation  which  is  to  be 

executed  next  is  always  completely  arbitrary.  No  a-priori  rules,  either 
deterministic  or  probabilistic,  determine  the  selection  or  exclusion  of  any 
operation.  Such  constraints  are  introduced  separately. 
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2.2. b Objects 

Ue  will  assume  that  the  state  of  a computational  system  is  comprised  of  a 
set  of  objects.  The  objects  are  presumed  not  to  overlap  and  the  contents  of 
the  objects  in  a given  state  completely  define  the  state.  In  the  domain  of 
programming  languages,  we  might  associate  an  object  with  each  variable.  In 
the  domain  of  operating  systems,  objects  might  represent  files,  directories, 
users  and  processes. 

Ue  assume  all  objects  have  fixed  unique  names  taken  from  some  set  NM 
which  may  be  different  for  each  system.  Ue  will  assume  that  NM  is  ordered 
by  some  lexicographic  ordering.  Formally,  a computational  system  is  a triple 
<S,A,NM>,  however  in  general  we  will  not  write  NM  explicitly  and  will 
continue  to  describe  a computational  system  simply  as  <2,A>. 

If  a is  the  name  of  an  object,  ue  write  o.a  to  mean  the  value  of  a in 
state  a.  Formally  we  may  think  of  a state  as  a vector  of  values  - the 
contents  of  each  object  in  the  state,  ordered  lexicographical  ly.  That  is, 
if  <nl,n2,...>  is  a vector  of  the  names  in  NM  in  lexicographic  order,  then 

0 s <o.  nl , c. n2, . . . > 

If  A isasetof  object  names  taken  from  NM,  then  we  write  a.  A to 

represent  just  that  portion  of  the  state  named  by  the  objects  in  A. 
Formally,  if  <al  ,ci2, . . . > is  a vector  of  the  names  in  A in  lexicographic 
order,  then 

0. A  <o.ctl,  o.a2, . ..> 

This  definition  permits  us  to  write 

01. A  = o2.A  for  (Vac A ) ( ol.a  = o2.a  ) 

Ue  define 

>>  Def  2-11  ol  = o2 
A 

01  = o2  Edef  (VafAH  ol.a  = c2.a  ) 
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That  is,  if  cl  = a 2,  then  states  cl  and  a2  may  differ  only  in  the  values 

of  the  objects  named  by  A.  For  the  special  case,  where  ffl  and  cr2  may  differ 

only  in  the  value  of  a single  object  a,  ue  define 

>>  Def  2-21  ol  - o2 
a 

ol  » a2  Bdef  (Va**a)  ( ol.a*  ■ o2.aft  ) 

Objects  may  themselves  have  some  internal  structure  (including  pointers 
to  other  objects).  However,  such  details  are  part  of  an  interpretation  and 
not  part  of  our  abstract  model.  As  an  example  though,  we  might  write  o.x.k 
to  mean  the  value  of  the  k’th  component  of  object  x in  state  o,  and  o.xtnl 
to  indicate  the  value  of  the  n’th  element  in  the  array-structured  object  x in 
state  o. 

The  objects  of  a system  do  not  necessarily  correspond  only  to  the 

internal  state  of  a machine  that  the  system  might  model.  Some  of  the 

objects  may,  for  example,  represent  input  and  output  devices.  The  model 
includes  no  requirement  that  objects  be  of  a fixed  size.  Thus  an 
arbitrarily  long  input  stream  could  be  modelled  by  an  arbitrarily  large 
object  containing  a representation  of  the  input. 


2.2.c  Operations 

Ue  formally  define  an  operation  8 as  a function  from  states  to  states. 
Semantically,  we  interpret 

8(o)  = o* 

to  mean  that  execution  of  operation  8 in  state  a results  in  state  or*.  Ue 
assume  that  the  result  of  8 is  always  defined. 

Ue  will  find  it  useful  to  describe  an  operation  8 in  terms  of  an  informal 
programming- 1 ike  language.  For  example,  suppose  that  8 were  defined  so  that 

(Vx*0) ( 8 (o) . x - a.  x ) 
a.  8 ( ct ) .0  = a. a 


I 


J 
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That  is,  let  o*  be  the  state  resulting  from  execution  of  8 in  state  o.  Then 
(3’s  value  in  o*  is  the  same  as  a’s  value  in  state  o.  The  value  of  other 
objects  are  the  9ame  in  both  states.  In  effect,  execution  of  8 copies  a’s 
value  to  (J.  We  might  define  8 in  the  programming  language-like  notation 

[ 0 - a ) 

and  write 

8:  0 *-  a 

In  place  of  8(cr)  = onv  we  may  write 
[ 0 «-  a 1 ( a ) = a* 


2.2.d  Executors  and  Generic  Operations 

In  a computing  system,  we  tend  to  associate  an  executor  with  each 
operation,  an  object  (traditionally  representing  a user  or  process)  presumed 
to  be  responsible  for  the  execution  of  that  operation.  He  assume  that  there 
is  some  function  Executor  and  we  interpret 

Executor  (8)  = m 

to  mean  that  m is  the  object  responsible  for  execution  of  8. 

The  fact  that  the  name  of  the  executor  is  determined  solely  by  the 
operation  may  conflict  with  the  astute  reader’s  intuition,  for  one  could 
easily  imagine  the  same  operation  executed  by  different  processes.  He  model 
such  an  operation  by  a set  of  operations  having  the  some  qener . c name. 

Suppose  "op"  is  the  generic  name  of  an  operation  that  could  be  executed 
by  any  process.  He  define  a set  of  operations,  op(pl).  op(p2),  etc.  such 

that  op(p)  defines  the  operation  op  executed  by  process  p.  For  each  p, 
op(p)  is  a distinct  member  of  A. 


Generic  operations  are  useful  more  generally  for  describing  classes  of 
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operations.  For  example,  a generic  "move"  operation,  move(p,0,cc)  might 
represent  the  operation  executed  by  process  p which  moves  the  contents  of  a 
to  f3.  For  each  p,  0 and  a,  move(p,0,a)  is  a distinct  memeber  of  A. 
move  (p, a)  can  be  described  as 

move  (p,(3,a) : (3  «-  a 

where  Executor!  move(p,|3,a)  ) ■ p 

By  defining  commands  in  this  way,  the  executor  of  a command  can  be 
determined  strictly  from  the  argument  of  the  command  itself,  independently 
of  the  state  in  which  the  command  is  executed. 

In  much  of  the  thesis,  the  notion  of  an  executor  may  not  be  pertinent  to 
the  discussion.  As  a result,  in  many  of  the  examples,  we  will  not  bother  to 
associate  an  executor  with  an  operation.  In  cases  where  we  do  distinguish 
the  executor,  the  executor  will  uniformly  be  placed  as  the  first  "argument" 
of  the  generic  name  as  in  "move"  above. 


2.2.e  Histories  and  Behaviors 


A history  is  a sequence  of  operations.  Execution  of  a history  in  a given 
state  means  sequential  execution  of  the  operations  in  the  history.  For 
example,  if  history  H is  the  sequence  of  operations  SI  8283,  then 


(81 82 83) (o)  » 83(82(81  (o) ) ) 


Pictorial ly 


C £1  Ccr) 


We  can  define  the  execution  of  a history  in  a state  recursively  as 


(HS)  (o)  <«  S(H (a) ) 
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where  A is  the  null  history  (no  operations)  - (not  to  be 
confused  with  the  lambda  calculus  "A"  which  is  also 
used  in  this  thesis) 

and  the  symbol  "<«=:'  is  to  be  read  as  "recursively  defined  as" 

He  write  & c H to  mean  that  operation  & appears  in  H.  For  example, 
S2  < SI  82 S3  and  S4  <t  S1S2S3. 

We  write  both  HH-.v  as  well  as  H & H*  to  mean  the  concatenation  of 
the  sequences  H and  H>v  (note  is  not  commutative). 

We  write  HI  < H2  to  mean  that  HI  is  an  initial  sequence  of  H2. 
Formal  I y 

» Def  2-4)  HI  < H2 

HI  < H2  sdef  (3H)  ( HI  & H = H2  ) 

If  a system  is  started  in  state  o and  some  arbitrary  sequence  of 
operations  H is  executed,  then  the  system  exhibits  some  Lehavior  which  can 
be  completely  described  by  the  pair  <o,H>.  We  call  a pair  <o,H>  a 

behav i or  or  a comoutat i on. 

Sect  ion  2.3 Mechanisms 


2.3 .a  Introduction 


We  may  think  of  a mechanism  as  a layer  interposed  between  a given 
computational  system  <I,A>  which  we  call  the  base  sustem  and  the  system 
<2’,A’>  as  provided  to  the  user,  which  we  call  the  augmented  sustem. 

I 

^ : _____  I ft 


I 
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Uhen  a user  executes  an  operation  S’  provided  in  the  augmented  system, 
the  mechanism  intervenes  and  translates  S’  into  execution  of  some  sequence  of 
operations  (e.g.  81S2S3)  in  the  base  system.  The  mechanism  may  even  decide 
to  execute  no  operation  at  all  - the  null  history  A.  If  the  mechanism 
represents  a level  o^  hierarchy,  then  the  sequence  of  operations  executed 
define  the  implementation  of  8’. 

The  mechanism  may  execute  different  histories  for  the  same  operation  in 
different  cases.  For  example,  suppose  a base  system  provided  the  operation 

move  (p,  (3,  a) : |3  «-  a 

which,  when  executed  by  process  p,  copies  the  value  of  a to  0.  Suppose  a 
protection  mechanism  augmented  this  system,  providing  the  user  instead  with 
the  operation  move’ (p,  (J, a) . Uhen  that  operation  is  executed,  the  mechanism 
executes  move  (p,  (3,  a)  in  the  base  system  on  I u if  process  p ha6  permission 
to  read  or  and  write  /3,  otherwise  the  mechanism  executes  no  operations  at  all 
- the  null  history  X. 

Addition  of  a mechanism  often  (but  not  always  - see  section  <gate>) 
implies  the  addition  of  components  to  the  state  as  well  - we  call  these 
additions  the  mechani sm  state.  For  example,  when  a protection  mechanism  is 
added  to  a system,  a mechanism  state  component  is  added  (in  the  form  of 
additional  objects,  or  extensions  to  objects  already  defined)  which  contains 
information  about  who  has  permission  to  access  what.  The  mechanism  state  of 
a protection  mechanism  is  often  called  the  protection  state,  and  is  often 
described  as  an  access  matrix  - see  appendix  A. 

The  state  space  I’  of  the  augmented  system  provided  to  the  user  may  be 
seen  as  consisting  of  two  parts  - the  mechani  sm  state  space,  which  we  write 
as  S’mech  and  the  state  space  1 of  the  underlying  base  system,  which  we 
may  now  think  of  as  the  data  state  space  of  the  augmented  system  ^'data* 
Pictorial ly 
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The  data  state  of  the  augmented  system,  need  not  be  the  same  as 

the  state  of  the  underlying  base  system,  1.  Instead,  the  mechanism  may 
present  ^’data  as  an  abstraction  of  1.  For  example,  if  a mechanism 

corresponded  to  a module  implementing  an  abstract  data  type  T,  then  Z’data 
might  contain  objects  of  type  T,  while  I would  instead  contain  objects 
comprising  the  representation  of  elements  of  types  used  in  T’s 
representation. 

Uhile  we  may  know  that  the  augmented  system  <Z’,A’>  is  composed  of  a 
base  system  <I,A>  with  a mechanism  M added  to  it,  a user  may  be 

presented  with  <Z\A’>  as  a "black  box",  taking  it  to  be  a base  system  to 
which  she  may  add  a new  mechanism  (implement  a new  level). 

A program  language  interpreter  is  an  example  of  a mechanism  that  provides 
an  augmented  system  in  which  operations  are  programming  language  statements 
and  the  data  state  consists  of  variables,  arrays  and  other  data  structures. 
In  the  base  system,  operations  are  machine  language  instructions  and  objects 
include  an  accumulator  and  memory  locations. 

Consider  the  way  that  a programming  language  interpreter  mechanism  may 
map  the  operation 

8’:  0«-a 

to  a sequence  of  machine  level  operations.  Ordinarily,  8’  might  be  mapped  to 
the  sequence  of  operations  in  the  base  system. 
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[ LOAD  mema  ] [ STORE  mem^  ) 

The  first  operation  loads  the  contents  of  the  memory  location  mema 
representing  a into  the  accumulator;  the  second  operation  then  stores  the 
contents  of  the  accumulator  into  the  memory  location  mem^  representing  0. 

As  in  the  "move"  example  above,  the  sequence  executed  in  the  base  system 
by  the  mechanism  might  be  different  in  different  cases.  If  a were  known  to 
be  0,  the  interpreter  might  map  S’  into  an  operation  that  simply  cleared  mem^ 

[ CLEAR  meni£  ] 

Finally,  if  a’s  value  were  known  to  be  the  the  same  as  0’s,  the  mechanism 
need  map  S’  into  no  sequence  at  all,  that  is,  into  the  null  history  A.  In 
general,  the  mapping  from  histories  executed  by  the  user  in  the  augmented 
system  to  histories  executed  by  the  mechanism  in  the  base  system  depends 
upon  the  (data  and  mechanism)  state. 

2.3. b — Formal  Definition 

Since  a mechanism  maps  states  and  histories  in  the  augmented  system  into 
states  and  histories  in  the  base  system,  and  since  a state/history  pair  is  a 
behavior,  we  can  define  a mechanism  M in  terms  of  of  a mapping  from 

behaviors  in  the  augmented  system  to  behaviors  in  the  base  system.  Ue  write 

Tfl<a’,H’>  = <o,H> 

if  the  mechanism  M maps  state  cr’  to  o and  history  H’  to  H (when  executed  in 
state  o’) . 

The  mapping  of  the  initial  state  is  independent  of  the  history 
subsequently  executed  in  that  state.  That  is 

If  Tfl<ol’,Hr>  = <ol,Hl> 
and  Tfl<a2’,H2’>  = <o2,H2> 


then 


ol’  = o2’ 


D 


ol  = o2 
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Since  we  can  ignore  the  history  in  mapping  the  states,  if 

Tfl<o’,H’>  « <o,H>  we  can  make  the  abbreviation 

Tfl(c’)  - o 

to  mean  that  state  o’  is  mapped  into  state  o in  the  base  system.  In  the 

example  above, 

Tp)(o’)  .mem0  « o\cc 
Tpj  ( cr*) . rnem^j  «=  o’./3 

That  is,  the  value  of  a in  the  augmented  system  is  the  same  as  the  value  of 
mema  in  the  base  system,  and  similarly  for  0 and  mem^. 

He  also  make  the  abbreviation 

TfllH’Mo’J  = H 

to  mean  that  H’  is  mapped  by  the  mechanism  to  H when  executed  In  state  o’. 

In  the  example  above,  we  would  define  so  that 

Tp|(&’)(o’)  » if  o’. a = o’. (3 

[ CLEAR  meni|j  I j_f  o’. a = 0 
[ LOAD  mema  I [ STORE  memp  ] otherwise 

These  two  abbreviations  are  defined  in  such  a way  that 

Tfl<0’,H’>  « < Tft(o’),  r^(H’)(o’)  > 

The  map  from  states  in  the  augmented  system  to  9tates  in  the  base 

system  on  I u depends  upon  values  in  the  data  state  space.  That  i s , if  two 
states  ol’  and  o2'  have  the  same  values  in  their  data  state  part  and  differ 
only  in  their  mechanism  state  part,  then  ol’  and  o2’  must  be  mapped  to  the 

same  state  in  the  base  system.  That  is 

Tfl(ol’)  - Tp|(o2’) 

The  values  in  the  mechanism  state  are  only  used  by  the  mechanism  to 
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determine  hou  histories  executed  by  the  user  are  to  be  mapped  into  histories 
executed  in  the  base  system  (though  the  mechanism  may  use  the  data  state  to 
determine  this  mapping  as  well). 

A mechanism  might  only  work  properly  if  its  mechanism  state  is  properly 
initialized.  Ue  describe  this  initial  constraint  on  the  mechanism  state  as 
defined  so  that 

'Pfl  ( o') 

holds  only  if  the  mechanism  state  part  of  state  o'  is  properly  initialized. 
Ue  want  to  ensure  that  is  defined  so  that  it  only  constrains  the 

mechanism  state  and  not  the  data  state.  In  effect  we  guarantee  that  the 
imposition  of  cannot  result  in  the  imposition  of  any  corresponding 

constraint  on  the  states  of  the  base  system. 


Formally  we  require 

I rM  ( tr’)  ) - ( rn(c’)  I <PM(o’)  I 

Ue  collect  the  details  discussed  above  aid  formally  define  a mechanism  as 


i 


fo I I ows: 
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» Def  2-5)  M is  a mechanism  from  <!’,&’>  to  <!,&>  iff 


a pair  < > 

where 

tf 

Tfl<0l\Hl’>  *= 

<ol,Hl> 

and 

rn<o2’,H2’>  ■ 

= <o2, H2> 

then 

ol’  - o2’ 

D.  ol  « 

t We  can  therefore  abbreviate  so  that 
if  Tfl<o’,H’>  « <a,H>  we  write 

Tfl(o’)  » o and  t^(H’)  (o’)  * H ) 

2.  I rM  (a’l  I - I Tfl(cr’)  I «Pn  ( a* ) I 


We  noted  above  that  two  states  ol’  and  o2*  may  differ  only  in  their 
mechanism  state  (both  satisfying  fj-|)  and  therefore  map  to  the  same  base 

n 

state.  We  will  find  it  convenient  to  create  the  notation  ol’  - o2’  for 

that  situation.  Formally 

» Def  2-B)  ol’  2 o2’ 

ol’  2 o2’  sdef 

<PM(ol’)  a ( rn (ol’)  - rn(o2’)  ) a <fy(o2  ) 


2.3.C  Homomorphism 

Earlier  in  this  section,  we  provided  an  example  of  a language  interpreter 
mechanism  that  would  map  the  operation  ( 0 *-  a ) in  the  augmented  system 
to  the  operation  t CLEAR  mem^  ] in  the  base  system  if  a were  0.  Suppose 

that  the  mechanism  performed  the  same  map  in  a state  o’  in  which  o’. a ■ 7 
instead.  Now 

[ 0 - a ) (a’).0  - 7 

since  the  semantics  of  [ 0 «-  a ] are  such  that  (subsection  2.2.  c)  its 
execution  copies  the  value  of  o to  0.  Since  for  any  state  o’, 

Tfl(o').meni0  - o’.0,  we  have 
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Tpj(  [ (i  *■  a 3 la’)  J.mem^j  = 7 


However 


C CLEAR  mem^  ](  r^(o’)  Lmem^  « 0 

Writing  [ 0 *-  a ) as  H\  the  mechanism  has  determined  to  be 

[ CLEAR  mem^  ),  yet  in  executing  H’  in  the  augmented  system,  the  value  of  0 
(and  therefore  of  mem^)  is  set  to  7.  In  effect,  the  mechanism  has  changed 
the  semantics  of  a CLEAR  operation  so  that  it  sets  <3  to  7 instead  of  to  0. 
Homomorphic  mechanisms  correspond  to  a "black  box"  vieu  of  base  systems.  To 
add  a non-homomorphic  mechanism,  one  has  to  be  able  to  "see"  inside  the 
“black  box"  in  order  to  alter  the  definitions  of  the  base  system  operations 
provided  by  it. 


rpj(  H’ (o’)  ).ment0  ■ 7 

( Tfl(H’)(o’)  ){  T|v|(o’)  ).meni|3  = 0 

If  a mechanism  always  correctly  translates  behavior  in  the  augmented 
system  to  behavior  in  the  base  system  (for  any  state  sati  tying  <fy|) , we  say 
its  mapping  is  homomorphic.  Formally  we  define 

>>  Def  2-7]  M is  homomorphic  i f f 

<Pf1  ( r ’)  o.  Tn(  H’(o')  ) = ( rn(H'>  (o')  )(  Tn(o'J  ) 

We  can  describe  homomorphism  pic  tor  tally  as 


c r' 


H'O') 


V4(0 


H’  is  executed  in  state  o'  resulting  in  state  H*(o')  which  is  mapped  to  a* 


. . 
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C T(H*(a’))  - o*  ].  The  behavior  <o’,H’>  Is  mapped  to  <o,H> 

t r<o',H’>  - <a,H>  ].  If  the  state  resulting  from  execution  of  the  behavior 

H(o)  is  the  same  as  a*,  and  this  relation  holds  for  any  behavior  <o,H>,  then 
r i9  homomorphic. 


Section  2.4 *>v*  Concurrent  Mechanisms 


2. 4. a ft**  Introduction 

In  this  section  we  show  how  a mechanism  may  be  formalized  to  model 

concurrent  execution  of  operations  provided  in  the  augmented  system.  Those 

mechanisms  that  do  not  model  concurrency,  but  are  sequential,  are  formally 

described  as  markov  mechani sms. 

When  operations  are  permitted  to  execute  concurrently,  the  resulting 
state  of  a computation  may  depend  upon  the  way  in  which  the  operations 

interleave.  Mechanisms  in  which  interleaving  has  no  effect  upon  the 
resulting  state  are  formally  defined  as  weak  I u consistent. 


2.4. b ttftft  Markov  Mechanisms 

Suppose  that  a base  system  provided  two  generic  operations,  81  and  82,  so 
that  Slip)  and  82(p)  denote  the  execution  of  81  and  82  respectively  by 
process  p.  That  is. 

Executor!  81 (p)  ) = Executor!  82 (p ) ) * p 

Imagine  that  we  want  to  guarantee  that  a process  p can  only  execute  the 
sequence  of  operat  ions  81  (p)  82  ( p ) . He  could  add  a mechanism  to  the  system 
that  would  only  make  a single  operation  8’(p)  available,  defined  so  that 
for  al I states  o' 

r ( S’  (p)  ) ’ o’  ) - 81  (p)  82  (p) 

Imagine  that  a process  executes  8’  and  then  executes  it  again.  Ue  imagine 
that  the  basv>  system  operations  would  be  executed  serially.  That  is 
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r ( 8’ (p)  8* (p)  )(  a’  ) « 81  (p)  82(p)  81  (p)  82(p) 

However,  suppose  that  8’  were  executed  by  two  different  processes  pi  and  p2. 
In  some  cases,  we  might  imagine  that  again,  there  would  be  no  interleaving 

r ( 8’ (pi)  8* (p2)  )(  olf  ) = 81  (pi)  82 (pi)  81 (p2)  82(p2) 

In  other  cases  interleaving  might  be  possible 

r ( 8’ (pi)  8’(p2)  ) ( o2’  ) - 81 (pi)  81 (p2)  82 (p2)  82 (pi) 

Ue  may  use  the  contents  of  the  mechanism  state  to  model  variability  in 
interleaving.  The  mechanism  state  is  presumed  to  contain  the  information 

that  tells  the  mechanism  (e.g.  - an  oracle,  see  [Milner  72),  (Cohen  75)) 
which  process  should  next  execute  an  operation  in  the  base  system.  By 
initializing  the  mechanism  state  differently,  the  mechanism  may  interleave 
the  operations  differently. 

Ue  will  now  consider  how  a mechanism  M might  be  characterized  that  does 
not  permit  interleaving.  Suppose  that  when  81’  is  executed  in  state  el', 
history  HI  is  executed  in  the  base  system;  when  82’  is  executed  in  o2’,  H2  is 
executed.  If  o2'  is  the  state  resulting  from  execution  of  81’  in  state  ol’ 
[ 81’ (ol’)  = o2’  ) , then  execution  of  81’82’  in  state  ol’  should  alwaus  result 
in  execution  of  HI  H2  in  the  base  system  if  there  is  no  interleaving.  A 
mapping  (and  the  mechanism  it  is  part  of)  that  satisfies  this  property  for 
every  state  o’,  is  said  to  be  markov.  Formally 

>>  Def  2-8)  t is  markov  i f f 

t(A)(o’)  = A 

t(H’8’)(o’)  = t(H’)  (o’)  S t(8’)  (H’(o’)) 

Theorem  2-1) 


If  r Is  markov 
then  r(Hl’H2’)  (o’) 


r (HD  (o’)  & t(H2’)  (HI’ (o’)  ) 
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» Def  2-9]  M is  markov  iff 
is  markov 

If  a mechanism  is  both  markov  and  homomorphic,  ue  say  It  is  markov 
homomorphic.  ^ 

Theorem  2-2] 

If  M is  markov 

and  Tp|(  S* ( 0* ) ) ■ ( TfllS’Mo')  )(  r^(o’)  ) 

then  M is  homomorphic 

2.4.c  ***  Weakly  Consistent  Mechanisms 

If  a mechanism  is  not  markov  and  operations  may  be  interleaved,  the 
resulting  state  of  a computation  may  differ  depending  upon  how  the 
operations  are  interleaved.  For  example,  suppose  that 

51  (p)  s a «-  0 

52  (p)  s a ♦-  a + 1 

For  any  state  o’,  we  find  that 

( SI  (pi)  S2(pl)  SI  (p2)  S2(p2)  )(  a’  ).cr  - 1 
( SI  (pi)  Sl(p2)  S2(p2)  S2(pl)  )(  o’  ).o  - 2 

Data  base  system  designers  [Gray  75]  and  those  interested  in  proving 
properties  of  parallel  programs  [lipton  75]  often  find  it  important  to  be 
able  to  show  that  no  matter  how  operations  are  permitted  to  interleave,  the 
resulting  state  is  the  same.  A mechanism  that  has  this  property  is  defined 
to  be  weakly  consistent.  Formally 

>>  Def  2-10]  M is  weakly  consistent  if_f 

el’  - e2*  d (VH’M  rhONjl'))  - tmIH’^’))  ) 


4 
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This  characterization  follows  from  the  fact  that  ol’  and  o2’  differ  only 
in  their  mechanism  state,  which  we  noted  earlier  is  responsible  for  different 
interleavings.  The  history  executed  in  the  base  system  if  H*  is  executed  in 
state  ol*  is  ( H’ ) ( erl  ’) . The  resulting  state  in  the  base  system  is 

( tm(H’)  (ol*)  )(  rn(ol’)  ).  If  Tfl  is  homomorphic  (which  we  will  assume),  the 

reulting  state  is  just  t^O-T  (ol’)).  As  a result,  to  determine  whether 
interleaving  affects  the  resulting  stats,  we  compare  trOHMoI’))  and 
tm(H*  (ct2*)  ) . 

Section  2.5  — Mechanisms  and  Behavioral  Constraints 

The  addition  of  a mechanism  to  a base  system  may  prevent  the  occurrence 
of  certain  behaviors  in  the  base  system.  For  example,  consider  the 
mechanism  M defined  so  that  the  single  operation  provided,  8\  is  always 
mapped  to  the  history  818283. 

Tfl<o\  S’>  =>  <o,  8182S3> 

SI  82 S3  can  only  be  executed  in  this  sequence.  The  behavior  <0,  S2 SI  S3> 
cannot  occur,  for  82  must  follow  81. 

He  can  characterize  those  behaviors  that  can  occur  by  a behavioral 
constraint,  a predicate  on  behaviors,  f.  Ue  say  that  M induces  ¥ if 
V(cr,H)  is  true  exactly  when  <o,H>  is  a behavior  that  can  occur.  For  the 
example  above,  if  M induces  T,  we  find  that  f(o,  818283)  but  -T(o,  8281  S3) . 

Formally,  the  set  of  base  system  behaviors  permitted  by  a mechanism  is 
just 

( rn<o,,H’>  I fyU’)  ) 

that  is,  the  set  of  all  behaviors  uhich  can  be  mapped  from  behaviors 
executed  in  the  augmented  system.  Ue  define 

>>  Def  2-11)  M induces  t iff 

YJa.H)  > <a,H>  < { Tn<c\H'>  I f^fo*)  I 


r 


Problems,  Mechanisms  & Solutions  ( 2.5  ) 


page  37 
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i 


A mechanism  might  be  added  to  a system  in  order  to  constrain  the  behavior 
of  a system  as  specified  by  Y.  Ue  might  call  al|  of  those  behaviors  that 
satisfy  Y acceptable.  Those  that  do  not  satisfy  Y might  be  deemed 
unacceptable. 

Ue  might  want  to  add  a mechanism  M to  a system  that  prevents  all 
unacceptable  behaviors.  Optimally,  such  a mechanism  might  onlu  prevent 
unacceptable  behaviors.  That  is,  M induces  Y.  A cheaper  mechanism  might 
prevent  some  acceptable  behaviors  as  well.  As  long  as  all  of  the 
unacceptable  behaviors  are  prevented,  ue  say  that  11  enforces  Y.  Formally 

>>  Oef  2-12]  M enforces  Y i f f 

<ct,  H>  t I rn<o’,H,>  I Yn(o’)  i o.  Y(o,H) 

or  equivalently 

(Vo’.H’H  <f>n(o’)  3 Y(rn<o',H’>}  ) 

or  al ternately 

«Pn(o’)  d (VH’i  ( Y(rM<a’,H’>)  ) 

In  chapter  4,  we  will  show  how  the  set  of  behaviors  characterized  by  Y 
may  represent  some  problem  we  would  like  to  solve.  The  addition  of  a 
mechanism  may  solve  that  problem  by  inducing  or  enforcing  Y. 

Section  2.6  Initial  Constraints 

2.6. a — Constraining  the  Base  System 

Ue  may  decide  to  constrain  a given  base  system  so  that  it  may  not  operate 
in  certain  initial  states.  In  so  doing,  we  prevent  the  occurence  of  certain 
behaviors  in  the  system  - those  behaviors  <o,H>  whose  initial  state  o is 
not  one  of  those  initially  permitted.  Ue  write  <P  to  characterize  such  an 
initial  constraint.  Y(o)  is  true  i f f o is  a permitted  initial  state. 


■ 


| 
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The  behaviors  induced  by  imposing  f are  exactly  those  whose  initial  state 
satisfy  <P.  Formal  ly 

>>  Oef  2-13]  induces  f i f f 

(Vo, H)  ( <P(o)  h Y(o, H)  ) 

By  preventing  the  occurrence  of  certain  behaviors,  the  imposition  of  an 
initial  constraint  <P  may  permit  a constraint  on  behavior  to  be  enforced.  He 
define 

>>  Def  2-14]  enforces  f j_f_f 
(Vo,  H)  ( <P(o)  o f(o,H)  ) 

If  <P  enforces  V,  then  the  imposition  of  guarantees  that  only 
acceptable  behaviors  (those  character ized  by  T ) will  be  permitted. 

Ue  introduce  the  notation 

>>  Def  2-15]  <Pi  contained  in  <P2 

<P1  S <P2  sdef  (Vo)  ( <f>l(o)  3 <P2(o)  ) 

<P1  is  contained  in  <P2  if  it  is  a stricter  constraint  (the  set  of  states 

satisfying  <P1  are  a subset  of  the  states  satisfying  *P2).  By  imposing 

stricter  initial  constraints,  more  unacceptable  behaviors  can  be  prevented. 

Theorem  2-3]  (proof  left  to  reader) 

I f $2  enforces  V 
and  fl  Q <f>2 

then  'PI  enforces  V 


Initial  constraints  may  or  may  not  be  invariant.  Invariance  is  defined  as 


Problems,  Mechanisms  & Solutions  ( 2.6. a ) page  39 


>>  Oef  2-16]  is  invariant  i f f 

<P(o)  d (VS)  ( <PU(o>)  ) 

Ule  noted  in  subsection  2.2.b  that  the  contents  of  an  object  could 
represent  a stream  of  incut.  An  initial  constraint  could  then  represent 
restrictions  on  the  input.  In  general,  there  is  no  reason  to  expect  that 
will  remain  invariant  as  values  are  input  from  the  stream. 

2.6. b Constraining  the  Mechanism 

Ue  may  decide  to  both  impose  an  initial  constraint  ’P  on  a base  system 
as  well  as  adding  a mechanism  M to  it.  Ue  will  find  it  convenient  to 
da  f i ne 

» Q§1  2-17]  M:4> 

(M:<P)  (o’)  sdef  4>n(o’)  a <P(rn(o’)i 


(\o(rr\Z  Ar£{>  ■ 1 

1 ^ *ecV\ 


M:<P  character i zes  the  initial  constraint  on  states  as  represented  in  the 
augmented  system.  It  includes  both  the  constraint  on  the  mechanism  state 
as  well  as  the  initial  constraint  imposed  on  the  base  system.  The 

set  of  behaviors  induced  in  the  base  system  when  is  imposed  and  M is  added 


can  be  characterized  as: 


I Tfl<o\ H’>  I (M:<P)(c’)  1 
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We  can  then  define 
>>  Def  2-18]  <<P,M>  induces  Y i f f 

Y(c,H)  8.  <o,H>  c [ t^<o’,H’>  I (Mi$)  (o’)  ) 

>>  Def  2-13J  <<P,  M>  enforces  Y i f f 

<o,  H>  c I Tn<o\H’>  I (M:Y)  (o’)  J o.  Y(o,H) 
or  equivalently 

(M:<P)  (a’)  d (VH'J  ( Y(rn<o’,  H’>)  ) 

In  the  case  that  M is  the  identity  mechanism,  or  ^ is  the  aluays  true 
predicate,  the  reader  can  verify  that  these  definitions  reduce  to  definitions 
2-13  and  2-14,  and  2-11  and  2-12  respectively. 

2,8.c  — rit  Layers,  of  Mechanism 

If  mechanisms  ere  added  to  a system  in  layers,  then  one  can  determine  the 
behavioral  constraint  Y induced  in  the  system  at  some  level  from  <f>,  the 
constraint  imposed  at  that  level,  and  M,  the  mechanism  provided  at  that 
level,  given  the  behavioral  constraint  Y’  induced  at  the  level  above. 
Formally  ue  can  define 

>>  Os*  2-20]  <<P,M>  induces  Y given  Y’  i f f 

Y(o,  H)  a.  <o,  H>  c { Tn<«r,,H’>  I (M:Y)  (o’)  a YMo’.H’)  I 


3 

i 


1 
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Chapter  3 - Decision  Mechanisms 


Section  3.1  — • Introduction 

In  this  chapter  we  discuss  a class  of  mechanisms,  decision  mechanisms, 
that  can  be  used  to  model  a wide  range  of  protection  and  control  (including 
synchronization)  mechanisms.  Ue  show  that  decision  mechanisms  induce  a 
class  of  behavioral  constraints  defined  as  monotonic,  and  further  show  that 
every  monotonic  behavioral  constraint  can  be  induced  by  some  decision 
mechanism. 

Ue  also  show  how  pseudo-nperations  may  be  added  to  a base  system  in  order 
to  specify  synchronization  problems.  These  pseudo-operations  are  meant  to 
correspond  to  synchronization  operations  that  must  be  provided  by  mechanisms 
added  to  solve  those  problems. 

A decision  mechanism  is  one  added  to  a ba9e  system  in  order  to  decide,  on 
an  operatior;  by  operation  basis,  whether  or  not  each  operation  in  the  base 
system  should  be  permitted  to  execute  or  whether  its  execution  should  be 
prevented.  For  example,  consider  the  base  system  <!,&>  with  defined 
operations  81,..., 8k.  81  is  an  operation  that  clears  the  disk. 

81:  disk  «-  0 

Our  task  is  to  add  a switch  to  this  system,  so  that  the  disk  may  only  be 
cleared  (81  may  only  be  executed)  if  the  switch  is  set. 

The  addition  of  the  switch  augments  the  base  system.  The  augmented 
system  it  produces,  has  the  following  properties: 

1.  The  data  state  space  of  the  augmented  system,  E’data  *s 
same  as  the  state  space  of  the  base  system  I. 

2.  The  mechanism  state  space  rmech  consists  of  a single  object 
"suitch"  whose  value  may  be  1 (indicating  that  the  switch  is  set) 
or  0 (indicating  that  the  switch  is  not  set). 
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3.  The  operations  A’  of  the  augmented  system  are  81’,...,  8k’. 

62’  through  8k’  are  defined  exactly  like  82  through  8k  respectively. 

81*  may  be  defined  as 

81’:  rf  switch  « 1 then  disk  «-  0 

In  effect,  adding  the  switch  makes  the  operation  81  unavailable  to  the 
user.  The  augmented  system  instead  provides  81’  which  checks  the  suitch 
before  performing  the  function  of  81,  that  is  before  clearing  the  disk. 

The  addition  of  the  switch  defines  a mechanism  M with  the  following 
properties: 

1.  a tt.  There  is  no  initial  constraint  on  the  mechanism 
state.  The  initial  state  of  the  switch  is  not  specified. 

2.  Tfl(o’)  = o'.NM  where  NH  are  the  names  of  the  objects  in  the 
base  system  ( switch  t NH  ) . 

3.  T|«j ( 8 i ’ ) ( o’ ) = 8i,  i = 2,...,k.  The  mechanism  directly 
implements  82’,..., 8k’  as  82,..., 8k  respectively. 

4.  When  the  user  executes  81’,  the  mechanism  executes  81  only  if 
the  switch  is  set.  If  the  switch  is  not  set,  no  operation  In  the 
base  system  is  executed  by  the  mechanism. 

(81*)  (o')  - 81  j_f  o’. switch  *>  1 

\ i_f  o’,  switch  • 0 

Having  added  the  switch,  we  may  feel  compelled  to  add  an  operation  to  the 
system  that  permits  the  switch  to  be  changed.  Ue  could  add  an  operation 
80’  to  the  augmented  system  which  flips  the  switch. 

80’:  switch  «-  1 - switch 

The  execution  of  80’  is  invisible  in  the  base  system.  The  mechanism 
executes  no  operation  in  the  base  system  when  80’  is  executed.  80’  affects 
the  mechanism  state  only.  Formally,  we  say  that  80’  is  r^-invisible  where 
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» Def  3-11  8*  is  t- invisible  j_f_f 

(VoM  ( r(8')  (o’)  = A ) 

Protection  mechanisms  are  excellent  examples  of  decision  mechanisms.  A 
base  system  may  provide  operations  that  copy  data,  perform  arithmetic 
operations  and  execute  programs.  The  addition  of  a protection  mechanism 
provides  a new  set  of  operations  corresponding  to  the  set  provided  by  the 
base  system.  When  an  operation  in  the  augmented  system  is  executed  by  a 
user,  the  mechanism  evaluates  some  protection  condition  In  order  to 
determine  whether  or  not  the  corresponding  operation  In  the  base  system 
should  be  executed. 

The  protection  conditions  may  often  be  modelled  as  an  access  matrix  (9ee 
Appendix  A)  which  comprises  the  mechanism  state  We  write 

<x,a>  (o’J 

to  describes  the  set  of  access  permissions  that  executor  x has  for  o in 
state  o’.  For  example, 

r c <x(a>(o’)  a w c <x,0>(a’) 

means  that  the  access  matrix  in  state  o’  indicates  that  x has  the  right  to 
read  ("r")  a and  to  write  ("w")  0 . 

Uhere  the  base  system  might  provide  the  operation 

move  (x, 0,  a) : 0 «-  a 

the  augmented  system  might  provide  the  operation 

move’  (x,0,  a)  s j_f  r c <x,a>  a u t <x,0> 
then  0 ♦-  a 


The  mechanism  would  be  defined  so  that 
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Tfl(  move*(x,0,a)  ) ( o’  ) - 

move(x,|3,a)  j_f  r t <x,a>(o’l  a w c <x,0>(a’) 

A otherwise 

That  is,  uhen  i.iove’(x,0,oc)  is  executed,  the  mechanism  executes 
move(x,£,cr)  in  the  base  system  only  if  the  the  access  matrix  indicates 
that  x has  the  appropriate  rights. 

Ue  noted  above  that  operations  invisible  to  the  base  system  may  be  added 
by  the  mechanism  in  order  to  provide  for  manipulation  of  the  mechanism 
state.  In  protection  systems,  these  operations  can  be  used  to  permit 
sharing  and  revocation  of  access.  (Note  that  nothing  prevents  operations 
which  are  not  invisible  from  altering  the  mechanism  state  as  a side  effect  of 
execution  as  well.) 

The  initial  constraint  on  the  mechanism  state  represents  an  initial 

constraint  on  the  possible  configurations  of  the  matrix. 

Section  3.2  Formalization 

Each  operation  provided  by  the  augmented  system  (e.g.  move’(x,0,a)  ) is 
mapped  either  a single  operation  in  the  base  system  (e.g.  move(x,0,a)  ) or 
into  no  operation  at  all.  Formally  we  say  that  the  mapping  is  direct. 

>>  Def  3-21  Tf|  is  direct  i f f 

tU’Mo’)  £ A U (X) 

where  M is  a mechanism  from  <2\A’>  to  <X,A> 

Ue  want  a formal  definition  of  a decision  mechanism  to  reflect  the  fact 
that  a mechanism’s  decision  to  execute  an  operation  in  the  base  system  is 
final.  Subsequent  behavior  can  have  no  effect  on  earlier  decisions. 
Further,  any  decision  made  by  the  mechanism  depends  only  upon  the  current 
state  and  not  the  previous  history  (except  as  it  may  be  encoded  in  the 
current  state.  For  example,  the  mechanism  may  store  in  the  mechanism  state, 
a record  of  the  history  executed). 
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If  8’  has  executed  after  H*  has  been  executed  in  state  o’,  the 
determination  of  whether  an  operation  should  be  executed  in  the  base  system 
or  not  depends  only  upon  8’  and  the  current  state  HMcr’).  Formally, 
must  have  the  property  that 

Tfl(X)  (o’)  ■ X 

Tfl (H’S’)  (o’)  - thIH’Ho’)  & rM(  S’)  Offs’)) 

that  is,  Tfl  is  markov  (definition  2-8). 

» Def  3-3J  M is  a runtime  mechanism  iff 

Tfl  is  direct  and 

Tfl  is  markov 

Decision  mechanisms  are  runtime  mechanisms  with  one  additional  property  - 
they  are  homomorphic  (definition  2-7).  When  an  operation  is  executed  In  the 
augmented  system,  a decision  mechanism  decides  only  whether  or  not  a 
corresponding  operation  may  be  executed  in  the  base  system.  Any  side 

effects  are  confined  to  changes  in  the  mechanism  state  only. 

>>  Def  3-4]  M is  a decision  mechanism  i_f_f 

M is  a runtime  mechanism  and 

M is  homomorphic 

The  reader  may  note  that  the  examples  of  mechanisms  in  the  previous 
section  were  indeed  homomorphic. 


Section  3.3  Gatekeeper  Mechanisms  and  Markov  Constraints 

In  this  section,  we  discuss  gatekeeper  mechanisms,  those  decision 
mechanisms  which  have  no  mechanism  state.  He  show  that  such  mechanisms 
induce  a class  of  behavioral  constraints  we  call  markov  (not  to  be  confused 
with  markov  mappings). 

If  there  is  no  mechanism  state,  and  if  the  mechanism,  in  mapping  the  data 
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state  of  the  augmented  system  to  the  base  system  does  not  Implement  an 
abstraction,  then  the  state  space  of  the  augmented  system  and  of  the  base 
system  a~e  the  same,  that  is  1 - 1'  and  t^(o’)  ■ o’. 

Since  there  is  no  mechanism  state,  the  mechanism  can  only  use  the  current 
value  of  the  data  state  to  decide  whether  or  not  an  operation  should  be 
executed  in  the  base  system.  That  is,  to  determine  whether  & should  be 
permitted  when  the  base  system  state  is  o,  the  mechanism  performs  some 
test  p(S)(o).  Formally,  for  each  operation  % provided  in  the  base 

system,  the  mechanism  provides  the  corresponding  operation  defined  so 

that 


S’(o)  = Mo)  if  p(&)  (o) 

A otherwi se 

This  mechanism  induces  the  behavior  that  can  be  recursively  described  as 


'Ho, A)  <==  tt 

Y(e.HS)  <«  Ho.H)  a p ( 8)  (H(  o) ) 

That  is,  <o,H5>  is  an  acceptable  behavior  (satisfying  f)  if  S is  permitted 
in  the  state  in  which  it  executes  - H(o)  (i.e.  if  p(S)(H(cr))  ),  assuming 
<cr,H>  was  also  acceptable.  We  will  write  V in  such  cases  as 

(markov)  Ho,  8)  s p(8)(c) 

We  next  formally  define  a markov  behavioral  constraint  and  show  that  any 
decision  mechanism  without  a mechanism  state  induces  such  a constraint. 

>>  Def  3-SJ  T is  markov  i f f 

f (a, A)  ■ tt 

Y(o,H8)  ■ 'Ho,  H)  a HMH(o) , S) 

>>  Def  3-6]  r is  Mate  isomorphic  iff 
ol’  - o2*  iff  t(oI’)  - t ( o2’) 
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State  isomorphism  is  a way  of  saying  that  there  is  no  mechanism  state, 
since  any  two  states  in  the  augmented  system  mapped  into  the  same  base  state 
must  themselves  be  the  same.  Formally,  we  can  shou  that  if  M is  a proper 
mechanism  (definition  2-5)  and  is  state  isomorphic,  then  must  be  the 
aluays  true  predicate  - indicating  that  there  is  no  mechanism  state  to 
constrain. 

Theorem  3-1] 

If  n Is  a mechanism 

and  Tfl  is  state  isomorphic 

then  a tt 

Theorem  3-2] 

If  M is  a runtime  mechanism 
• and  Tfl  is  state  isomorphic 
and  M induces  t 

then  f is  markov 

Sect  ion  3.4 Sequent  ial  Control  Mechanisms 

In  this  section,  we  demonstrate  how  decision  mechanisms  may  be  used  to 
model  sequential  control  mechanisms,  those  that  induce  a base  system  to 
behave  as  if  it  were  executing  a sequential  program. 

The  underlying  base  system  defines  a set  A of  operations  which  may  be 
executed  in  any  order.  The  mechanism  state  of  a sequential  control 
mechanism  specifies  the  order  of  execution  of  the  operations. 

He  specify  a sequential  control  mechanism  so  that  its  mechanism  state 
contains  a specification  of  the  program  to  be  executed  plu9  a pc  (program 
counter)  which  indicates  which  operation  in  the  program  is  to  be  executed 


> 


: 

i 
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The  mechanism  provides  a single  operation  S’  which  can  be  Interpreted  as 
meaning  “execute  the  next  instruction  (operation)”.  Suppose  that  the 
mechanism  state  in  state  o'  indicated  that  54  shoufd  be  executed  next.  Then 
1^(5’)  (a’)  - 54. 

Ue  may  model  a sequential  control  mechanism  by  specifying  a mechanism 
state  containing  two  objects.  [ Other  models  might  do  just  as  well.  This 
one  is  convenient  for  our  purposes.  ] 

1.  pc  - the  program  counter 

2.  code  - an  object  defined  so  that  codeti)  indicates  the  name  of 
an  operation  to  be  executed  uhen  the  value  of  the  pc  is  i.  codeti) 
either  names  a base  system  operation  or  a "control"  operation  that 
only  alters  the  pc  (e.g.  a "goto"). 

For  example,  if 
code  C7)  = "54" 

thun  54  is  to  be  executed  when  the  value  of  the  pc  is  7.  That  is,  if 

a’. pc  «■  7 then  t^(5’)(o’)  = 54.  As  a side  effect  of  execution  of  54, 

the  mechanism  also  adds  1 to  the  pc,  so  that  5’(o’).pc  - 8. 

If  the  value  of  the  pc  is  i and  codeti)  contains  the  name  of  a control 

operation,  then  t^(5’)(o’)  = X.  A control  operation  has  no  effect  on  the 
data  state,  that  is  Tfl(5’(a’))  = r^lo’).  A control  operation  only  changes 
the  value  of  the  pc,  which  is  in  the  mechanism  state. 

Ue  will  be  content  to  arbitrarily  define  three  control  operations:  goto, 
branch  and  halt. 

goto  (n) : pc  ♦-  n 

branch(a,n) : j_f  a then  pc  «-  n el se  pc  «-  pc  + 1 

halt:  pc  *-  0 


For  example,  if  a’. pc  = 8 and 


•1 
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code [8]  =*  "goto (3)" 
then  8’(o’).pc  «*  3.  We  write 
control  (o’) 

to  mean  that  o’.codetil,  where  i is  the  current  value  of  the  pc 
( o’. pc  ),  names  a control  operation  rather  than  an  operation  defined  by 
the  base  system. 

Ue  will  interpret  a pc  of  0 as  indicating  that  th'  program  has  halted. 
Subsequent  execution  of  S’  has  no  effect.  That  is,  if  o’. pc  - 0,  then 
TflfS'Mcr’}  =*  X and  S’(o’).pc  * 0. 

If  NM  names  the  objects  defined  in  the  base  system  (all  objects  but 
code  and  pc),  then  can  formally  be  defined  a9 

Tfl(a’)  - o’.NM 


Tfll&’Mo’)  = A rf  o’. pc  » 0 

X j_f  control  (o’) 

8 otherui se 

where  o’,  code  (o’,  pc) 


’8" 


the  initial  constraint  on  the  mechanism  state  may  specify  the  initial 
value  of  the  pc  (usually  1)  and  may  constrain  the  code  object  as  uell, 
thereby  9Deci fuinq  a proper tu  of  the  program  represented  in  the  code  ob iect. 
In  particular,  fyj  may  fully  specify  a program.  For  example,  the  flowchart 
program 


1 

J 
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UH- 


can  be  represented  by  the  initial  constraint  on  the  mechanism  state 


s o’,  pc 
a a*,  code  [1] 
a o’,  code  [2] 
a o’,  code  [3] 
a o’,  code  [4] 


= 1 


"branch (a, 3) " 
"84" 

" 87" 

"halt" 


If  ffllo’)  and  o’. a is  false,  then 

Tfl(S’Mo’)  = a ( branch  is  a control  operation  ) 

Tfl ( 8’8’)  (o’)  = 84 
Tn(8’8’8’)  (o’)  = 8487 

Tfl  ( 8,8’8,8’ Mo’)  = 8487  ( after  87,  the  system  "halts"  ) 


He  can  formally  define  8’  (the  single  operation  supplied  by  the 
augmented  system  - which  means  "execute  an  operation")  as 
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S’fo’KNM  - o’.NM  if  o’. pc  - 0 
o’.NM  if  control  (o’) 

8 (o’.NM)  otherwise 

uhers  o’.codeto\pc]  - "8" 

8*(o’).pc  = 0 j_f  o’. pc  « 0 

^control  ,0,)'PC  H control  (o’) 

uhere  o’,  code  (o’,  pc]  - MScontro|M 
pc  + 1 otherwise 

S’ (o’),  code  « o’,  code 

Note  that  the  code  component  always  remains  unchanged.  The  reader  may 
determine  that  M is  indeed  homomorphic,  and  thus  M is  a decision  mechanism. 

A control  mechanism  induces  a constraint  on  behavior  that  reflects  the 
execution  of  the  problem  it  encodes.  For  example,  the  sequential  control 
mechanism  initialized  according  to  as  defined  above  induces  the 

behavioral  constraint 


V(o,H)  = H = X 


V 

{ a.  a a H - 84  ) 

V 

( o.a  a H = 8487  ) 

V 

( -’O.a  a H = 87  ) 

That  is. 

if  a. a 

is  true,  the  only  histories  permitted  are  X,  84  and  8487. 

If  a. a 

is  false 

, the  only  histories  permitted  are  X and  87. 

Section 

3.5  Multiprogram  Control  Mechanisms 

In  this  section,  we  show  how  to  extend  the  sequential  control  mechanism 
so  that  concurrent  execution  of  a system  of  programs  can  be  modelled, 
including  synchronizat ion  operations.  Instead  of  specifying  a single  pc  and 
code  object  in  the  mechanism  state,  we  associate  a pc  and  code  component 
with  each  executor;  i>e  call  this  the  program  component  of  the  executor.  For 
example,  o’.y.pc  is  the  value  of  x’s  pc  in  state  o’. 


Problems,  Mechanisms  & Solutions  ( 3.5  ) 


page  52 


Instead  of  providing  a single  operation  S’,  a multiprogram  control 
mechanism  provides  a set  of  operations  S’(x)»  Uhen  S’(x)  is  executed  in 
the  augmented  system,  the  mechanism  executes  the  operation  determined  by  x’s 
program  component. 


Formally,  is  defined  so  that 


rn(  S’  (x)  ) ( o’  ) 


A j_f_  o’. x.pc  =»  0 

A 11  control  (o’) 

A H Executor (5)  * x 

S otherui se 

uhere  o’,  x.  code  [o’,  x.  pel  » "S" 


That  is,  when  executor  x next  executes,  the  mechanism  executes  the  operation 
pointed  to  by  x’s  pc  (unless  its  pc  is  0)  as  long  as  the  operation  is 
supposed  to  be  executed  by  executor  x. 

Following  [Lipton  733  , we  show  how  a synchronization  mechanism  may  be 
embedded  in  this  mechanism.  First,  we  may  add  objects  to  the  mechanism 
state  (like  semaphores)  that  represent  the  synchronization  state.  fyj  then 
also  specifies  the  initial  value  of  the  synchronization  state  (the  initial 

value  of  the  semaphores).  The  operations  P and  V [Dijkstra  G8a3 , when 

executed  by  x,  can  be  modelled  by  the  control  operations 

P(x,sem):  jl  sem  > 0 then 

( sem  «-  sem  - 1;  x.pc  «-  x.pc-  + 1) 

V(x,sem):  ( sem  <-  sem  + 1;  x.pc  «-  x.pc  + 1 ) 

Note  that,  if  the  value  of  sem  is  0,  execution  of  P(x,sem)  leaves  the 

value  of  x’s  pc  the  same,  so  that  the  next  time  process  x executes  an 
operation  ( S’(x)  is  executed  in  the  augmented  system),  the  P is  attempted 
again. 


Suppose  the  code  component  of  process  i ( i - 1,2  ) contains 
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s 

i 

s 

, 


coded]  = "P(i,seni)" 
code  t2]  = " S ( i ) " 
code  133  - "V (i , sem) " 

and  the  value  of  the  pc  is  initially  one  for  both  processes.  Then 

tm(  8’(1)  ) ( a’  ) = X 

[ P(l,sem)  executed  ] 
rM(  8’(1)  S’ (2)  ) ( o’  ) = * 

t P 12, sem)  executes  and  "fails"  1 
rn(  S'  (1 ) S’  (2)  S’  (1 ) Mo’)  = 8(1) 

rn(  S’  (1)  S’  (2)  S’ (1)  8’ (2)  ) ( o’  ) - 8(1) 

( P(2,sem)  tries  again  ] 

rn(  S’  (1 ) 8*  (2)  S’  (1 ) 8’  (2)  S’  (1 ) ) ( o'  ) ■>  8(1) 

( V (1 , sem)  executes  ] 

rn(  S’ (1 ) 8’ (2)  S’(l ) S’ (2)  S’(i)  S’(2)  ) ( o’  ) - 8(1) 

[ P(2,sem)  finally  "succeeds"  ] 

rn(  S’ (1 ) S’ (2)  S’ (1 ) 8’ (2)  8’(1)  S’ (2)  S’ (2)  ) ( o’  ) - 8(1)  8(2) 


! 

| 


I 

i 

j 


( This  section  has  described,  a mul t (programmed  control  mechanism 
in  which  a synchronization  mechanism  has  been  embedded.  It  is 

possible  to  define  a pure  synchronization  mechanism  that  is  not 
embedded  in  a control  mechanism.  For  each  operation  8 provided  by 
the  base  system,  the  mechanism  would  provide  an  operation  8’  with 
exactly  the  same  effect.  In  addition,  it  would  provide  P and  V as 
invisible  operations.  ) 


Section  3.G  ***  Mechanisms  & Problem  Specifications 

In  this  section,  we  show  how  the  definition  or  a base  system  may  be 
extended  to  include  pseudo-operations,  useful  in  specifying  the  behavior  of 
a system. 

The  specification  of  the  2nd  Reader-Ur i ter  problem  ICnurtois,  Heymans  & 
Parnas  711  states  that  writers  must  hove  priority  over  readers.  That  is,  if 
both  a reader  and  a writer  are  waiting  to  use  the  same  resource,  then  the 
writer  will  gain  access  before  the  user.  It  is  shown  in  detail  in  (Greif  75] 


A 
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that  the  controversy  surrounded  the  solution  is  due  to  a certain  fuzziness 
as  to  when  the  resource  is  actually  requested  and  freed. 

We  show  how  to  formally  indicate  when  a resource  has  been  requested  or 
freed  by  adding  the  pseudo-operations 

req(x)  and  free(x) 

to  the  base  system.  They  are  both  no-ops  which  will  be  executed  by  the 
mechanism  when  executor  (process)  x requests  or  frees  a resource  (we  will 
assume  a single  resource  here  to  keep  things  simple). 

We  assume  that  some  control  mechanism  augments  the  base  system.  In 
particular,  we  will  assume  that  the  multiprogram  control  mechanism  defined  in 
the  previous  section  is  used.  He  will  define  two  additional  control 
operations  that  may  be  named  in  code  interpreted  by  that  mechanism. 

Preq(x.sem):  rf.  sem  > 0 

then  ( sem  «-  6em  - 1;  x.pc  «-  x.pc  + 1; 

x. block  «-  ff  ) 
e I se  x. block  ♦-  tt 

Vf  ree  (x,  sem) : sem  «-  sem  + 1 

These  two  operations  are  defined  exactly  like  P and  V,  except  that  Preq 
sets  x. block  (the  mechanism  state  is  extended  so  that  a "block"  component  is 
added  to  each  executor)  depending  upon  whether  the  process  is  blocked. 

Most  importantly,  while  execution  of  P and  V is  invisible  in  the  base 
system,  execution  of  Preq  (its  first  execution  only  if  the  process  becomes 
blocked)  and  Vfree  and  mapped  into  executions  of  req  and  free  in  the 
extended  base  system.  That  is,  t^j  is  modified  so  that 

Tfl(  S’  (x)  ) (o’)  « req(x)  j_f  -o’,  x.  block 

a o',  x.  code  (o’,  x.  pcj  = "Preq  (x,  sem) " 

* free(x)  j_f 

o’,  x.  code  (o’,  x.  pc]  = "Vfree  (x,  sem) " 


rM(  S’  (x)  Mo’) 
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In  effect,  a user  of  the  augmented  system  explicitly  indicates  where 
requests  and  frees  occur  by  using  Preq  and  Vfree  respectively  in  place  of  P 
and  V.  The  following  example,  adapted  from  the  one  in  the  previous  section, 
indicates  hou  the  behavior  is  mapped  from  the  augmented  system  to  the  base 
system. 

Suppose  that  the  code  component  of  process  I (i  - 1,2  ) contains 

code  111  » "Preq  ( i , sent) " 

code  121  - " 8 ( i ) " 

code  131  ■ "Vfree  (i , sem) " 

and  the  value  of  the  pc  is  initially  one  for  both  processes.  Then 

tm(  8’(1)  8’ (2)  8* (1 ) 8’ (2)  S’(l)  8’(2)  8’(2)  ) la’)  - 
req(l)  req(2)  8(1)  freed)  8(2) 

The  set  of  acceptable  behaviors  can  then  be  specified  formally  in  terms 
of  the  way  that  ordinary  base  operations  and  the  req  and  free  operations 
interleave  (as  in  (Greif  75)  and  {Riddle  73)). 

This  example  suggests  that  problem  specifications  may  generally  require 
the  addition  of  pseudo-operations  to  a base  system  that  will  have  to 
correspond  in  some  way  to  ordinarily  invisible  operations  (e.g.  P and  V) 
provided  by  the  mechanism.  The  pseudo-operations  represent  an  abstract 

specification  of  the  primitive  actions  relevant  to  the  problem  domain  (req 
and  free  are  relevant  because  we  are  considering  synchronization  problems). 
The  definition  of  the  mechanism  indicates  when  these  primitive  actions  can  be 
considered  to  have  taxen  place. 

A similar  approach  may  be  useful  in  specifying  protection  problems  as 
well,  though  we  have  not  yet  investigated  what  the  appropriate  primitives 
(pseudo-operations)  might,  in  general,  be. 


■ 
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Section  3.7  Monotonic  Behavior 


3. 7. a Induced  by  Decision  Mechanisms 


He  noted  in  section  2.5  that  mechanisms  induce  constraints  on  the 
behavior  observed  in  the  base  system.  In  this  section,  we  will  show  that 
the  class  of  behaviors  induced  by  decision  mechanisms  can  be  described  as 
monotonic. 

>>  Def  3-71  Y is  monotonic  i f f 
H2  > HI  d.  Y ( o,  H2)  o Y(o,Hl) 

Monotonicity  guarantees  that  if  some  behavior  <o,H2>  is  acceptable 

(satisfies  Y ),  then  any  earlier  behavior  <o,Hl>,  where  HI  < H2,  must 
also  have  been  acceptable. 

Theorem  3-3] 

If  Y is  markov 
then  Y is  monotonic 

Every  decision  mechanism  induces  a monotonic  behavioral  constraint.  More 
general ly 

Theorem  3-4] 

If  M is  a runtime  mechanism 
and  M induces  Y 

then  Y is  monotonic 


3. 7. b 


***  Construction  of  an  inducing  Mechamnism 


Any  monotonic  behavioral  constraint  can  be  induced  by  adding  some 
decision  mechanism  to  a base  system  (and  possibly  imposing  some  initial 
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constraint).  In  this  section,  we  uill  shou  how,  given  an  appropriate  y, 
such  a mechanism,  which  we  designate  as  My  - < Ty,  ^ >,  can  be 

constructed. 

For  each  operation  in  the  base  system,  My  provides  a corresponding 
operation  S’  in  the  augmented  system.  We  will  write  8’  <*  & to  indicate 
this  correspondence.  Whenever  operation  8’  is  executed,  the  mechanism 
evaluates  Y(o,H8),  uhere  8’  ~ 8,  and  where  <o,H>  is  the  behavior 

already  executed  in  the  base  system.  The  mechanism  executes  8 only  if 

't'(o,H8)  is  true.  This  implies  that  the  mechanism  must  somehow  remember  the 
initial  state  a and  the  history  H already  executed.  The  mechanism  state 
must  contain  all  of  this  information. 

If  NM  are  the  names  of  the  objects  defined  for  (the  data  state)  I, 
then  define  NM*  to  name  a set  of  objects  that  will  hold  a copy  of  the 
initial  state.  The  mechanism  state  consists  of  the  objects  NM*  as  uel  I as 
an  object  HIST  that  remembers  the  history  executed.  The  data  state  space 

of  the  augmented  system  is  the  same  as  the  state  space  of  the  base  system. 

That  is, 

'■y(o’)  « o’.  NM 

Initially,  no  history  has  been  executed  and  the  contents  of  NM  and  NM* 
are  the  same.  Formally 

<*>y(o’)  a a’.  HIST  = A a a’.NM  = o’.NM* 

For  each  operation  8,  define  8’  so  that 

8*  (o’)  .NM*  = o’.NM* 

8’  (o’)  .NM  - U t(  o’.NM*,  o’.  HIST  S 8 ) 

then  8(  o’.NM  ) else  o’.NM 


8’  ( o’) . HI  ST  - i_f  T(  o’.NM*,  o’. HIST  S 8 ) 

then  o’,  HIST  & 8 el  se  o’.  HIST 


NM*  remains  the  same;  it  remains  a copy  of  the  initial  data  9tate. 
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Using  NM>v  and  the  past  history  which  is  in  HIST,  the  mechanism 

determines  whether  S can  execute.  If  so,  the  data  state  is  appropriately 
changed  by  allowing  8 to  execute.  As  a side  effect,  HIST  is  updated  to 

reflect  the  fact  that  8 executed.  Of  course,  Ty  is  defined  eo  that  It  Is 

markov  and 

ry(8’)  (o’)  8 if  T(  g’.Nfl*,  o’.HIST&8  ),  8’  ~ 8 

X otherwi se 


Theorem  3-5J 

fly  is  a decision  mechanism 

Theorem  3—6] 

If  T is  mono  tonic 

then  there  is  some  ‘P  such  that 
•op,  My>  induces  t 


Sect i on  3.8  — >v»v»v  Consistent  Mechanisms 


3. 8. a ***  Introduction 

In  previous  sections,  we  argued  that  once  a mechanism  was  added  to  a 
system,  a user  would  know  of  its  existence  and  would  realize  that  her 
interaction  was  with  the  augmented  system.  However,  one  might  imagine  that 
a user  ,does  not  know  that  a mechanism  has  been  added,  and  believes  she  is 
still  interacting  with  an  original  base  system.  The  effect  of  each  operation 
may  appear  to  be  the  same,  however,  when  operations  are  attempted,  they 
sometimes  are  not  executed  - exactly  in  those  cases  where  the  decision 
mechanism  prevents  their  execution. 

For  example,  suppose  a base  system  provides  the  operation  move(x,)3,a) 
which  moves  the  contents  of  a to  0 when  executed  by  x.  A protection 
mechanism  is  added  to  the  system  and  the  augmented  system  instead  provides 
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the  operation  move’ (x,f3,<x) . When  this  operation  is  executed,  the 
mechanism  only  executes  move  (x,  3,  a)  if  x has  the  appropriates  access 
rights  for  a and  (i . If  x does  not  have  the  appropriate  rights,  the  user 

will  note  that  her  attempted  execution  of  move(x,0,a)  fails. 

We  find  that  when  decision  mechanisms  are  added,  a base  system  may  appear 
to  act  inconsistently  to  an  observer  of  the  base  system.  We  discuss  peak 
and  s tronq  consi stencu  - tuo  uays  in  which  consistency  may  be  guaranteed. 
We  also  introduce  reduct  ion,  a notation  used  to  indicate  the  history 
actually  executed  given  the  history  attempted. 

— 3 . 8 . b I'c.'nV  Strong  Consistency 

Mechanisms  with  state  may  appear  to  act  capriciously  or  in-onsi stent  I y to 
an  observer  who  can  only  view  the  base  system.  Consider  a mechanism  that 
only  permits  an  operation  8 to  execute  if  some  switch  in  the  mechani_sm 

state  is  set.  An  observer  of  the  base  system  may  find  that  in  one  case  8 
may  initially  be  permitted  to  execute  while  in  another  case  it  may  be 
prevented,  even  though  the  data  (observable)  state  is  the  same  in  both 
cases.  In  the  first  ca'*',  switch  is  set,  in  the  second  case,  it  is  not. 

Such  apparent  inconsistencies  cannot  occur  if  there  is  no  mechanism 
state.  However,  consistency  may  still  be  obtained  if  there  is  a mechanism 
state,  as  long  as  it  is  suitably  constrained  by  fy.  In  the  example  above, 
•Ppl  might  have  initially  guaranteed  that  switch  was  set,  and  therefore,  8 
would  always  initially  be  permitted. 

Formally  we  define 

>>  Def  3-81  M is  strongly  consistent  i f f 

ol*  2 o2’  d (VH’I  ( TM(H’)(on  - TflCH’)  (o2’I  ) 

That  is,  if  two  states  are  observed  to  be  the  same  in  the  base  system  and 
the  same  history  is  executed  in  the  augmented  system  in  both  cases,  then  if 
M is  strongly  consistent,  the  same  history  will  be  executed  in  the  base 
system  in  both  cases. 
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The  mechanism  state  may  be  so  constrained  by  that  only  a single 

initial  configuration  of  the  mechanism  state  is  permitted.  Ue  then  say  that 
the  mechanism  is  strongly  constrained.  is  an  example  of  a strongly 

constrained  mechanism.  Strongly  constrained  mechanisms  are  always  strongly 
consistent. 

>>  Oef  3-9]  fl  is  strongly  constrained  j_f£ 

ol'  Q o2*  3.  ol’  - o2’ 

Theorem  3-7]  (proof  left  to  reader) 

If  H is  strongly  constrained 
then  11  is  strongly  consistent 

Suppose  that  is  not  strongly  consistent  and  that 

Tflcol’,  8’>  - <o,  8>  while  Tfl<cr2\  8’>  * <o,\> 

If  fl  induces  Y,  then  Y(cr,S)  holds  because  <ol\ 8*>  is  observed  as 
<o,  8>.  However,  this  does  not  necessarily  imply  that  execution  of  8 is 
state  o will  aluays  be  alloued.  In  particular,  both  ol'  and  o2*  are  observed 
as  o (they  only  differ  in  their  mechanism  state),  yet  attempted  execution  of 
8 in  the  latter  case  will  not  be  permitted. 

In  general,  suppose  that  11  induces  Y and  Y(o,H).  Execution  of  H in 
state  a can  only  be  guaranteed  if  fl  is  strongly  consistent. 


3.8.  c 


Art*  Reduction 


Reduction  formally  describes  the  history  actually  allowed  by  any 
consistent  decision  mechanism  (more  generally,  any  consistent  mechanism  that 
induces  a monotonic  behavior)  given  the  behavior  attempted. 


Suppose  that  the  history  SI  8283  were  attempted  in  some  base  system,  and 
the  mechanism  decided  to  permit  81  and  83  to  execute,  but  not  82.  The 
induced  behavior  constraint  Y would  have  the  property:  flo, 81), 

-Y  (cr,  81  82) , Y'  ( ct,  81  83) . The  history  actually  permitted  to  execute  is  8183. 
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I 

K 

The  history  alloued  to  execute  depends  in  general  upon  the  state  In  which 
the  history  was  attempted.  An  operation  may  be  permitted  to  execute  in  one 
state  but  not  another  (even  for  a consistent  mechanism  - the  decision  may 
depend  upon  values  in  the  data  state).  Given  a consistent  decision 
mechanism  that  induces  t,  if  H Is  attempted  in  state  o,  we  write  the 
history  actually  permitted  to  execute  as 

H/o'V 

Remember  that  the  history  is  attempted  from  left  to  right,  and  the 
mechanism  permits  execution  of  an  operation  only  if  t would  be  satisfied.  So 
we  can  define  H reduced  by  f in  or  as 


» Def  3-10)  H/ffT  (recursively  defined) 

< «=  ” A 

(HS)/af  <== 

let  R be  H/fff  in 

i_f  T(o,RS)  then  RS  el  se  R 

Reduction  only  produces  histories  that  satisfy  T. 


Theorem  3-8) 


If  Y(o,A) 

then  f(  o,  H/„Y  ) 

and  if  f is  monotonic,  the  set  of  histories 
the  set  of  reduced  histories  that  satisfy  t. 

Theorem  3-3) 

If  f is  monotonic 

then  HMo.H)  o.  H =*  H/fff 


that  satisfy  t is  the  same  as 


J 


It  is  convenient  to  define  H reduced  by  T as 
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» Dei  3-111  H/Y 

h/y  .def  *o.  ( H/0Y  ) ( o ) 

Ue  see  that 

(H/T) (o)  - ( H/0f  ) ( o ) 

which  is  the  resulting  state  when  H is  attempted  in  state  a. 


3.8.d  ***  Ueak  Consistency 

When  a decision  mechanism  that  is  not  strongly  consistent  is  added  to  a 
system,  the  state  of  the  mechanism  may  affect  the  execution  of  a history 
attempted  in  the  base  system.  However,  the  resulting  state  may  be  the  same 
in  any  case.  Formally 

ffl’  2 ff2*  d (VH’M  Tn(H’(crH  = Tfl(H’ (o2*))  ) 

Ue  have  already  defined  this  property  (definition  2-10)  as  weak  consistency. 
Theorem  3-101 

If  M is  strongly  consistent 

and  M is  homomorphic 

then  M is  weakly  consistent 
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Chapter  4 - Enforcement  Problems 

Section  4,1  Introduction 

In  this  chapter  we  define  a behavioral  problem  as  one  that  can  be 
expressed  as  a constraint  on  behavior.  A class  of  these  problems, 
enforcement  problem,  are  solved  by  imposing  an  initial  constraint  on  the 
system  and/or  adding  a mechanism  that  enforces  the  behavioral  constraint. 

Ue  define  static  problems  as  a special  case  of  behavioral  problems  - 
those  in  which  the  state  of  a system  is  required  to  satisfy  some  property  no 
matter  what  history  is  executed.  A static  specification  of  a problem  is 

suitable  when  the  particular  system  (including  any  mechanisms  it  may  already 
contain)  is  specified,  otherwise,  a behavioral  specification  is  generally 
required.  When  we  wish  to  solve  an  enforcement  problem,  specified 
behavioral  ly,  in  a particular  system,  the  behavioral  specification  can  be 
converted  to  a static  one.  Static  specifications  are  generally  more  useful 
for  proving  the  correctness  of  solutions. 

He  discuss  maximal  solutions  to  problems  and  their  relationship  to  the 
unciec i dabi I i ty  results  discussed  in  [Harrison,  Ruzzo  & Ullman  751.  Ue 
indicate  why  maximality  is  not  necessarily  an  important  requirement  for  a 
so  I u t ion. 

* 

Finally,  we  develop  a methodology  for  determining  the  solution  to  a 
behavioral  problem.  First  an  initial  constraint  is  found  which  eliminates 
some  unacceptable  behavior  (behavior  that  does  not  satisfy  the  given 
constraint).  Secondly  a mechanism  is  found  which  eliminates  the  remianing 
unacceptable  behavior.  Ue  present  a simple  example  of  the  application  of 
this  approach  in  a system  containing  multiple  mechanisms. 


Ue  define  a behavioral  problem  to  be  a constraint  on  the  behavior  of  a 
system,  a description  of  those  behaviors  we  deem  acceptable.  Ue 
character  ize  these  acceptable  behaviors  as  '♦'problem*  so  ^problem*0' 

is  true  only  if  <or,H>  is  an  acceptable  behavior. 


Ue  solve  a class  of  behavioral  problems,  enforcement  problems,  by 
guaranteeing  that  only  acceptable  behaviors  may  occur  in  a system.  In 
chapter  2,  we  noted  that  unacceptable  behaviors  could  be  prevented  in  two 
ways  - by  imposing  an  initial  constraint  on  the  system,  which  we  designate 
^solve  or  by  adding  some  mechanism  fl.  That  is,  '♦'problem  ke  s0'vecl  by 


finding  a pair  <<f 


solve 


,f1>  such  that 


<<psolve-ri>  enforces  Yprobl 


em 


Ue  do  not  require  that  <<^solve’^>  induce  '♦'problem*  a resu**» 

acceptable  behaviors  may  be  prevented  by  the  solution  as  well  as  unacceptale 
ones.  If  our  goal  is  to  prevent  as  few  unnecessary  behaviors  as  possible, 
then  a solution  that  induces  '♦'problem  lJ0U,d  certainly  be  optimal.  However, 
one  might  imagine  other  criteria  for  determining  adequate  or  optimal 
solutions.  These  are  discussed  in  section  7.3. 


Ue  may  want  to  guarantee  that  some  property  of  the  state  of  a system 
remain  satisfied  over  execution  of  any  history,  Ue  uill  call  such  a problem 
a static  enforcement  problem  and  describe  it  as  ^problem  where 
<Ppr0biemIoI  is  true  only  if  o satisfies  the  given  property. 

An  example  of  a static  enforcement  problem  is  the  following  Access 
Pr ob I em  (section  1.3):  Cohen  should  never  gain  write  access  to  the  Salary 

file.  Ue  can  represent  this  formally  as 


^problem*0*  a w f <Cohen.Sal ary> (o) 

Static  enforcement  problems  include  the  safety  problems  discussed  in 
[Harrison,  Ruzzo  & UMman  751.  The  safety  problem  for  right  q ie  the  same 
as  the  9tatic  problem 


A 
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<^,problem(tr)  s <Vx,y)(  q « <x,y>(o)  ) 

That  is,  the  problem  is  to  guarantee  that  no  object  may  ever  have  q-rights 
for  an  object. 

The  static  problem  ‘♦’problem  can  be  seen  as  a -shorthand  notation  for  the 
behavioral  problem  '♦'problem  de*ined  so  that 


’problem 


(o,H)  s <P. 


’problem^*)) 


That  is,  a behavior  <u,H>  is  acceptable  only  if  its  resulting  state,  H(o), 
satisfies  <Ppr0bieni* 

He  defined  (definition  2-19)  <<P80lve,^>  enforces  '♦problem  38 

^!^sol  ve*  ^ o ) o (VH  ) ( '♦'problem^TM<0  ♦ 

We  can  alter  that  definition  in  the  following  way  so  that  it  refers  to  static 
problems. 

» Del  4-1]  <*B0|ve'M>  enforces  ‘♦’problem  ILL 

(n^solve)(8,)  ^ (VH’)(  Voblem^MtHMa’)))  ) 

For  the  cases  where  on  I u the  initial  constraint  or  the  mechanism  is  used 
to  solve  '♦’problem'  we  define 

» Dei  4-2]  ‘♦’solve  enforces  ‘♦’problem  Hi 

'♦’solve*8*  3 *VH)  C Voblen,(H(a))  ) 

>>  Def  4-3]  M enforces  '♦’problem  Hi 

V8’*  d (VH’H  Vob|em(Tn(H*(o-)))  ) 

In  section  1.3,  we  argued  that  static  specifications  are  useful  given  a 
particular  system,  while  behavioral  specifications  are  suited  to  more  general 
problem  statements.  For  example,  the  statement  of  the  access  problem 


Problems,  Mechanisms  & Solutions  ( 4.2  ) 


page  66 


‘♦problem*0*  ■ w « <Cohen,Salary>(o) 

implied  an  access  matrix  mechanism  that  permits  Cohen  to  modify  Salary  only 
when  Cohen  has  write  access  to  it  (as  in  the  system  described  in  appendix 
A). 

In  order  to  state  a more  general  behavioral  specification,  we  need  to 
assume  a general  predicate  "Uacc".  Ue  write  Uacc(a,o,S)  to  mean  that  in 
executing  S in  state  a,  a write  access  is  made  to  object  a.  An  appropriate 
statement  of  the  problem  would  then  be 

(markov)  tprob , em (a,  S)  = 

Cohen  * Executor(&)  o -Uacc (Sal  ary, a, S) 

That  is,  Cohen  is  never  to  be  permitted  to  execute  an  instruction  that 
causes  a write  access  to  be  made  to  the  Salary  file. 

When  ue  wish  to  solve  this  problem  in  a system  in  which  an  appropriate 
mechanism  is  already  included,  we  can  conver t the  behavioral  specification  to 
a-  static  one.  In  the  system  defined  in  Appendix  A,  if  Cohen  does  not  have 
write  access  to  the  Salary  file,  then  no  operation  executed  by  Cohen  can 
cause  a write  access  to  Salary.  Formally, 

w e <Cohen,Salary> (o)  :> 

( V 6 ) ( Cohen  = Executor(S)  o -Uacc (Sa I ary , a, &)  ) 

As  a result,  we  can  convert  the  specification  of  '♦'problem  ‘♦’problem* 

Formally,  this  follows  from  the  theorem 

Theorem  4-11 

If  ‘♦’solve  enforces  problem 

and  '•'problem  is  markov 

and  Voblem<0)  (Vi)  • '•'problem*0’**  * 

then  <*>solve  enforces  fprob,em 


The  value  of  such  a conversion  will  be  demonstrated  more  forcefully  in 
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Sect i on  4.3  Maximal  Solutions 

Different  combinations  of  initial  constraints  and  mechanisms  lead  to  a 
variety  of  different  solutions  to  behavioral  problems.  However,  even  if  we 
restrict  our  attention  to  initial  constraints  alone,  there  may  be  more  than 
one  solution.  We  may  find  more  than  one  <PB0|ve  that  enforces  ^problem* 
that  is,  more  than  one  'Pgoivg  such  that 

^solve^  3 (VH)  ( 't'propi  t o.  H)  ) ("t"-arrows  for  emphasis) 

t 

However,  there  is  a maximal  solution,  one  that  least  constrains  the  set  of 
initial  states.  It  is 

W*  3 <VH)<  Voble.<«.H)  > 

t 

[ We  note  here  that  the  maximal  solution  does  not  necessarily 

induce  ^problem*  For  example,  consider  an  arbitrary  system  with  a 
single  operation  S.  The  maximal  solution  to 

Voblem(o-H)  s H » X v H = S 


which  certainly  does  not  induce  ^problem1  ^ 

The  following  example  illustrates  the  value  of  non-maximal  solutions. 
Consider  a system  that  includes  as  two  objects,  a bank  vault  and  a robber. 
The  robber  can  rob  the  bank  unless  the  vault  is  locked  or  the  robber  is 
drunk.  For  now,  the  only  action  in  this  system  we  will  focus  on  is  the 
attempted  robbery,  which  can  be  represented  by  the  single  operation 

SI:  rf  -’drunk  (robber ) a -d ocked (vaul  t)  the  . 

( - obber . money  *-  robber,  money  + vault. money; 
vau  1 1 . money  *-  0 ) 

Our  problem  is  to  find  some  way  to  guarantee  that  the  robber  can  get  no 
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money  by  robbing  the  vault.  This  can  be  stated  formally  by  the  following 
markov  behavioral  constraint 

(markov)  '♦'problem*®'  ^ ■ cr.  robber,  money  • h (or) . robber . money 

v o. vaul t. money  • 8 ( o) . vaul t. money 

From  the  definition  of  the  system,  ue  see  that  this  can  be  accomplished 
if  either  the  vault  is  locked,  the  robber  is  drunk  or  the  vault  is  empty. 
The  maximal  solution  to  '''problem  ls 

•Pma><(o)  a drunkto.  robber)  v I ocked  (o.  vaul  t ) 

v o.  vaul  t.  money  ■=  0 

As  a practical  matter,  a more  restrictive  solution  will  suffice 
^solve*^  5 I ocked  ( o.  vau  1 1 ) 

that  is,  the  problem  is  solved  by  constraining  the  initial  states  to  those  in 
which  the  vault  is  locked,  without  regard  to  whether  the  vault  is  empty  and 
certainly  without  depending  upon  drunk  bank  robbers. 

[Harrison,  Ruzzo  & Ullman  751  as  well  as  this  author  (unpublished)  have 
shown  that  even  under  very  special  circumstances  the  safety  problem  in 
projection  matrix  systems  is  undecidable.  In  our  terminology,  that  means 
that  there  is  no  algorithm  that  can  determine  ''’max’  *he  'eas<-  restrictive 
solution,  even  for  static  problems. 

Undecidability  is  not  so  negative  a result  a9  it  might  seem.  ^max  's 
after  all  a maximal  solution.  In  general,  the  user  of  a protection  system 
is  not  seeking  a maximal  solution,  but  rather  any  reasonable  solution  that 
will  solve  the  problem.  In  the  bank  robbery  example,  a reasonable  solution 
meant  locking  the  vault.  In  the  Salary  file  example,  an  admini s'.rator  might 
not  really  care  about  the  obscure  circumstances  under  uhich  Cohen  might  be 
prevented  from  gaining  write  access  to  the  Salary  file.  She  i9  really  only 
interested  in  showing  that  a particular  solution  will  prevent  Cohen’s  access. 

The  question,  "What  makes  a solution  reasonable?"  will  be  discussed  in 
more  detail  in  section  7.3. 
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Section  4.4  A Methodology  for  Solving  Problems 


He  may  solve  a behavioral  problem  by  imposing  an  initial  constraint 
'Pgoive  and  adding  a mechanism  M to  a system.  Instead  of  determining  them 
together,  we  may  find  find  the  following  approach  more  convenient:  We  first 

pick  ^solve*  Imposing  ^soive  eliminate  many  of  the  unacceptably 

behaviors.  Next  determine  M so  that  its  addition  eliminates  the  remaining 
unacceptable  behaviors.  Formally,  define 


>>  Def  4-4] 


■^sol ve’^solve*  enforces  ^problem  Hi 


^solve^  ^ ^H)(  fsolve(o,Hl  d fproblem(a,H)  I 

That  is,  ‘Pgoive  only  eliminates  all  unacceptable  behaviors  if  the  behaviors 
are  already  constrained  by  fso|ve.  Once  tg0|ve  is  determined,  a mechanism 
must  be  provided  to  enforce  tso|ye.  Our  expectation  is  that  enforcement  of 
Vso,ve  is  less  complex  (or  can  be  accomplished  more  easily  or  more 


reasonably)  than  enforcement  of  ^problem’ 
mechani  sir 
Formal  I y 


solve’ 


mechanism  that  enforces  f,.0|ve  can  *hen  be  8how" 


together  with  the 
to  enforce  ^problem* 


Theorem  4-2] 


<<^sol  ve,'^solve>  enforces  fprob|ew 
and  <<psolv&’f1>  enforces  Tso|ve 


then  <<*)solve’ri>  enforces  tprobl 


em 


That  is,  after  determining  the  remaining  unacceptable  behavior,  find  a 
mechanism  M whose  addition  prevents  those  behaviors.  That  mechanism,  along 
with  ^solve’  then  solves  the  original  problem. 

For  static  problems  we  may  similarly  define 

» Def  4-5J  <^so|ve’tsolve>  enforces  Voblem  Hi 

‘‘’solved  ^ (VH)(  t80|ve(a,H)  d <Pprob|em(H(o))  ) 
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Theorem  4-3] 

If  <<psolve-'*'solve>  enforces  Voblem 
and  <<psolve‘n>  enforces  tgo|V€ 
and  M is  homomorphic 

then  <4*301  ve’n>  enforces  4>problem 

The  technique  discussed  here  is  useful  even  when  the  mechanism  is  already 
specified,  as  long  as  only  the  mapping  is  specified,  and  not  the  initial 

constraint  on  the  mechanism  state  <fy.  After  finding  a <4*s0| ve’^sol ve> 
that  enforces  4prob|eni  tor  ,+'prob  | em) , we  may  try  to  find  an  appropriate 
80  that  the  mechanism  M,  now  fully  specified,  eliminates  the  remaining 
unacceptable  behavior  specified  by  Tgo|ve. 


Section  4.5  Protection  and  Control 

In  this  section,  we  will  apply  the  methodology  discussed  in  the  previous 
section  to  solve  a behavioral  problem,  Ue  will  consider  a system  that 
contains  not  one,  but  tuo  mechanisms,  a protection  mechanism  as  well  as  a 
multiprogram  control  mechanism  (section  3.5). 

Consider  a system  with  two  kinds  of  objects,  processes  and  files,  and  a 
9 ingle  generic  operation 

copy  (x,(J,a) : j_f  process(x)  a file(fj)  a file(a) 

then  0 *-  a 

where  Executor!  copy(x,0,a)  ) * x 

Let  us  suppose  that  a mechanism  based  on  an  access  matrix  is  added  to 
this  system.  The  augmented  system  instead  provides  the  generic  operation 

copy  (x, 0, a) : j_f  r c <x,a>  a w c <x,(3> 

a process(x)  a file  (^5)  a fiie(a) 
then  <3  *■  a 


The  multiprogram  control  mechanism  M (as  defined  in  section  3,5)  prevents 
arbitrary  execution  of  operations.  The  control  mechanism  state  associates 
with  each  process  a program  counter  (pc)  and  a code  component  containing  the 
operations  to  be  executed  by  the  process.  The  mechanism  guarantees  that 
operations  are  executed  in  the  base  system  only  when  pointed  to  by  the  pc. 
That  is,  if  Executor (8)  is  x,  then  x can  execute  8 in  state  c'  only  if 

a’,  x.  code  [o’,  x.  pc)  * "8" 


Now,  suppose  that  we  want  to  solve  the  following  behavioral  problem 
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(markov)  '*'pr0b|em(<J.  &)  * o-Salary  » S ( o) . Salary 

that  is,  guarantee  that  the  value  of  the  Salary  file  remains  unchanged  over 
execution  of  any  operation.  The  most  direct  uay  to  solve  this  problem  is  to 
ignore  the  fact  that  there  is  a control  mechanism  augmenting  the  system,  and 
simply  guarantee  that  no  process  has  the  right  to  urite  the  Salary  file. 
That  is,  define 

^solve*0*  s (Vx)  ( w ? <x,Salary>U)  ) 

He  can  easily  prove  that 

^sol ve  enforces  Yprob|em 
This  follows  from  the  theorem 
Theorem  4-4] 

If  'I’solve  ‘s  invar'ant 
and  ^problem  is  markov 
and  ^solve^0*  3 (VS) ( VproP|em(o,  8)  ) 

then  ^solve  enforces  fprob, 

em 

'Pgoive  -,s  invariant,  since  in  the  simple  system  we  have  defined,  there  is  no 
way  to  change  the  access  matrix.  ^problem  ba9  been  defined  as  markov. 
The  protection  mechanism  (which  is  part  of  the  base  system)  guarantees  that 
if  no  process  has  the  right  to  write  the  Salary  file,  the  contents  of  the 
Salary  file  cannot  be  changed. 

Suppose  that  for  some  reason,  this  solution  is  not  allowed,  and  the  best 
ue  can  manage  is  the  following 

^solve*0*  5 (VxxAdmini  strator)  ( w <t  <x,Salary> (c)  ) 

That  is,  the  system  administrator  may  not  be  prevented  from  having 
permission  to  write  the  Salary  file.  The  problem  may  be  solved  only  if  the 
administrator  does  not  exercise  this  right  - that  is,  does  not  write  the 
Salary  file.  Formally  this  property  can  be  stated  as 
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(markov)  ^eol ve*ff* ^ * 

(Va)  ( S «*  copy  (Administrator , Salary,  a)  ) 

Then,  since  copy  is  the  only  operation  defined  in  this  system,  we  can  show 
that 


<<^>sol ve'^sol ve>  ®nf°rce9  ^problem 

Since  the  base  system  is  augmented  with  a multiprogram  control  mechanism, 
^solve  can  be  enforced  by  guaranteeing  that  the  Administrator’s  code 
component  does  not  contain  an  operation  whose  execution  would  alter  file. 
If  Tfl  is  the  multiprogram  control  mechanism  mapping  defined  in  section  3.5 
and  is  defined  as 

<fy(cr’)  ■ (Va,i)(  c*. Administrator. coded]  «• 

"copy (Administrator, Salary, a) " ) 

then  M enforces  Tso|ve* 

So,  we  first  imposed  an  initial  constraint  ^s0|ve  that,  bW  itself,  did 
not  enforce  '♦'problem*  Rather,  imposition  of  ^dye  8till  permitted  the 
occurrence  of  certain  unacceptable  behaviors  (those  not  satisfying  ^so|ve]* 
These  remaining  unacceptable  behaviors  could  then  be  eliminated  by  specifying 
a constraint  on  the  mechanism  state  that  guaranteed  that  M could 

enforce  H'goiyg. 

In  a sense  this  example  is  too  simple.  An  application  of  the  methodology 
that  would  be  more  clearly  useful  might  use  a '♦'solve  was  no*  Markov. 

Such  an  example  is  left  to  future  research. 

Section  4.6 ***  Constraining  the  Augmented  System 

In  section  4.4,  we  showed  that  if  the  mapping  a mechanism  is 

already  provided,  then  a behavioral  problem  can  be  solved  by  imposing  both 
an  initial  constraint  ^g0lve  on  *be  ba9e  system,  and  an  initial  constraint 
on  the  mechanism  state.  Since  the  user  is  presented  with  an  augmented 
system,  combining  both  the  base  system  and  the  mechanism,  it  may  be  useful 
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to  specify  both  constraints  as  the  single  constraint  ^’sjlve  which 
constrains  the  initial  state  of  the  augmented  system. 

In  this  section,  we  uill  show  that  any  constraint  ^’s0|ve  °n  the  initial 
state  of  the  augmented  system  can  be  decomposed  into  'fy  and  ^golve*  The 
possibility  of  decomposition  is  not  obvious  for  two  reasons. 

1.  Uhile  ‘P’goive  constrains  the  augmented  system  state,  ‘Pgoive 
constrains  the  base  system  state.  The  mapping  between  them,  r^, 
need  not  be  trivial . 

2.  'fyj  must  satisfy  the  property 

{ T^(a’)  I ^(e’)  i = ( Tfl(cr’)  } 


Ue  shal  I now  show  that  any  can  be  decomposed  into  a and  a 

such  that  <f*  = M:<P. 

Theorem  4-51 

Define  <P  so  that 

'P(o)  m O { I Tfl(o’)  I <P(o’)  i 

Define  'fy  so  that 

^(cr’)  a P’  (o’)  v -<P(rn (a*) ) 

Then  <P’  m <P:M 

and  I t^(o’)  I ?n(o’)  1 = i r^(o’)  ! 

For  example,  the  solution  to  the  problem  in  the  previous  section  can  be 
written  as 

^solve^0*^  * (Vo,  i)(  o’.  Administrator,  code  [i]  * 

"copy (Administrator , Sal  ary, a) " ) 
a (VxxAdmini strator) ( w 4 <x, Sal ary>  ( o')  ) 


which  ua9  decomposed  as 
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fylo’)  ■ (Va,i)(  a’. Admini strator . code U]  * 

"copy (Administrator, Salary, a) " ) 

'Pgoiygto')  ■ (VxnAdmini strator)  ( u t <x,Salary>(c)  ) 

so  that  ^8o|ve(9'J  - A <p8olve(TM(°,,) 
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Chapter  5 - A Case  Study 

Section  5.1  Introduction 

This  chapter  provides  a case  study  of  the  solution  to  the  following 
protection  problem:  Imagine  that  some  system  contains  a set  of  sensitive 

objects.  These  objects  are  to  be  altered  only  by  programs  which  have  been 
verified  to  treat  these  objects  properly. 

He  will  solve  this  problem  for  the  base  system  described  in  Appendix  A. 
t Readers  unfamiliar  with  capabi I i ty-based  protection  systems  are  advised  to 
turn  to  appendix  A before  proceeding  ] It  is  described  as  containing  a 
capability-based  protection  mechanism.  Each  object  in  the  system  has  two 
components,  a C-list  and  a Value-part.  The  C-lisx  of  an  object  indicates 
which  other  objects  may  be  accessed  by  (uhen  it  represents  an  executor)  or 
through  it.  The  Value-part  of  an  object  holds  arbitrary  data.  In  the  case 
of  objects  which  represent  executors,  the  Value-part  contains  a 

representation  of  the  program  executed  by  that  object.  The  system  also 
models  dynamic  creation  of  objects,  including  (via  the  "call"  operation) 
creation  of  new  executors. 

The  remainder  of  this  chapter  is  organized  in  the  following  way:  He  first 
specify  the  problem  formally  as  a behavioral  enforcement  problem  in  notation 
independent  of  the  mechanism  provided.  Next,  using  the  definition  of  the 
mechanism,  we  specify  a static  problem  that  is  easier  than  the  given  problem 
(any  solution  to  the  easier  problem  solves  the  given  problem  as  well).  He 
develop  three  increasingly  general  solutions  to  the  problem.  Finally  we 
discuss  the  nature  of  solutions  to  protection  problems  and  the  impact  of 
exercises  such  as  this  one  on  the  design  of  protection  mechanisms.  In 
particular,  we  we  may  find  that  additional  mechanisms  are  required  or 
desirable  in  order  to  solve  problems  or  to  enhance  reliability. 
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Section  5.2  The  Problem 

We  may  formally  state  the  problem  described  above  as  follows: 

(markov)  tprob 

I em  ^0’ ^ s 

-’Trusty  (Executor  ( S) ) o (V(3)  ( Sensi  ti  ve  (0)  o.  cr. <3  - S(cr).0  ) 

[ Instead  of  o.(J  = &(o).0,  we  might  have  written 
^Uacc (|3,  o,  8)  as  in  section  4.2  I 

where 

Trusty(x)  means  executor  x is  trusted  to  only  execute  programs 
verified  to  treat  sensitive  objects  properly. 

Sensi  t i ve  ((3)  means  (3  i s a sensitive  object.  He  shall  assume 
that  sensitive  objects  may  not  be  executors. 

The  treatment  of  objects  as  Trusty  or  Sensitive  is  external  to  the 
system.  No  object  itself  contains  any  information  indicating  how  we  (as 
theorem  provers)  will  treat  it. 

Treated  as  an  enf orcement  problem,  the  formal  specification  above 
requires  that  no  operation  executed  by  a program  that  has  not  been  verified 
be  allowed  to  alter  the  contents  of  a sensitive  object.  J_t  j_s  important  to 
note  that  th  i s speci  f i cat  ion  re  I i es  i n no  wau  upon  the  representat  i on  of  the 
protec t i on  sustem. 

We  will  actually  solve  an  easier  problem.  But  first  we  must  note  two 
facts  about  the  system  described  in  appendix  A. 

1.  All  operations  are  specified  so  that  no  executor  x may  alter 
another  object  (3  unless  x has  permission  to  write  |3  - that  is, 
w ( <x,f3>. 

2.  No  object  x may  act  as  on  executor  unless  s c <x,x>.  No 
operation  allows  sharing  of  an  "s"-ricjht. 
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Therefore,  ue  can  solve  the  problem  by  guaranteeing  that  no  non-trusty 
executor  may  ever  have  urite  access  to  a sensitive  object.  Actually  we  will 
solve  an  easier  problem.  Ue  will  shou  hou  to  guarantee  that  no  non-trusty 
executor  has  anu  access  to  sensitive  objects.  I Ue  will  discuss  in  section 
5.8  how  one  might  adapt  the  last  solution  given  so  that  reads,  but  not 
writes,  can  be  permitted.  ] This  problem  is,  in  effect,  the  Hidden 
Facilities  problem  (section  1.3).  Sensitive  objects  represent  the  facilities 
that  are  to  be  hidden  from  certain  users.  Trusty  executors  represent  those 
users  who  are  trusted  to  use  those  facilities.  Formally,  we  will  be  solving 
the  problem 

(markov)  Yprobl  en,(o,8)  a 

-Trusty (Executor (8) ) a (V0) ( Sensitively)  a -Acc( y,  o,  8)  ) 

where  Acc(y,o,8)  means  that  (3  is  accessed  as  the  result  of  executing  8 in 
state  o. 

Ue  will  convert  '♦'problem  to  the  stat'c  problem  ’♦problem*  defined  as 

♦problem*0*  5 <Vx,(3,q) 

( s c <x,x>(o)  a q t <x,(J>(o)  ) 
a.  Sensi  t i ve  (|3)  a Trusty(x)  ) 

Formally  this  substitution  of  problems  can  be  justified  by  theorem  4-1  - 
that  is 

If  ♦solve  enforces  ^problem 
and  f problem  is  Markov 

and  Voblem*0*  3 *VS)(  Voblem*0***  * 

then  ♦solve  enforces  '♦'problem 


Below,  ue  prove  that 

♦problem*0* 

= <V8)  ( '♦'problem*0*  **  * 

By  inspection  of 

the 

operations 

defined  in  Appendix  A,  ue  find 

x - Executor(8) 

A 

Acc (0, o, 8) 

a. 

S C <X,X>(ff) 

A 

( x » y v 

q < <x, y> (a)  ) 
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That  is,  an  executor  can  only  access  itself  or  some  other  object 

for  uhich  it  has  some  access  right.  If  we  assume  that 

'Pproblem^0*  holds,  then  we  can  show  that 

x » Executor  (8)  a Acc(#,cr,  8)  o. 

Sensitive!#)  o ( x = # v Trusty(x)  ) 

Since  executors  cannot  be  sensitive 

x = Executor (8)  a Acc(#,<t,8)  d. 

Sensitive!#)  d Trusty(x) 

which  is  just  a rearrangement  of  'h'prob  I em  ^ 

To  find  a <Pso)ve  that  enforces  ^prob|em,  we  might  find  a <Pso|ve 
that  is  invariant  and  stricter  (though  hopefully  not  much  stricter)  than 
^problem-  F°™aMy 

Theorem  5-1) 

^ ^solve  s ^problem 

and  ^solve  's  invariant 

then  ^solve  enforces  ^oblem 

If  such  a solution  could  be  found,  then  the  protection  mechanism  would  be 
shown  to  provide  all  the  tools  necessary  to  solve  the  problem.  However,  we 
will  see  below  that  additional  constraints  on  the  behavior  of  the  system  are 
required,  which  means  that  some  additional  mechanism  must  be  added.  That 
mechanism  is  assumed  to  be  a control  machanism  (as  in  section  3.5)  which 
must  be  constrained  so  as  to  further  specify  the  behavior  of  tru9ty 
executors.  Ue  must  find  a pair  <^$0 1 ve’ ^so I ve>  such  *ha*  ^solve  can  be 
enforced  by  the  control  mechanism  (section  A. 4)  and  such  that 

<<Psolve*tsolve>  enforces  fpPob|em 

As  above,  we  can  pick  ^s0lve  *°  be  contained  in  ^problem"  a 

behavioral  constraint  'I’solve  's  ceouired,  then,  while  we  cannot  e pect 
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^solve  to  be  invariant  (else  ts0|ve  would  not  be  needed  at  all),  we  can 
expect  it  to  be  tso|ve- Invariant.  That  is,  <P90|ve  remains  satisfied  so  long 
as  only  histories  satisfying  ¥_ o(ve  are  executed.  Formally, 


•P  ie  f-invariant  iff 


d.  <P(o)  d <P(H(a) ) 


i nvar i an  t 


> enforces  <P, 


To  demonstrate  t, 
useful : 


we  will  find  the  following  theorem 


invariance 


If  V is  markov 

and  f(o,8)  o.  <P(o)  d <P(Uo)) 


then  •P  is  ¥- i nvar i ant 


Throughout  the  renainder  of  this  chapter,  we  will  choose  '♦'80|ve,s  that  are 
markov  and  we  will  show  that  <<pso| ve'^sol ve>  enf°rc®8  ^problem  by  ®hou,n9 


Creation  Rules 


In  the  system  described  in  appendix  A,  new  objects  may  be  created  by  the 
operations  "call"  and  "create".  Formally,  it  is  best  to  treat  new  objects 
as  if  they  were  not  actual  lu  created,  but  rather,  were  selected  from  a pool 
of  existing  oojects  that  have  not  yet  been  used.  Therefore,  we  assume  that 
no  object  has  access  to  any  of  these  objects  prior  to  the  time  of  their 
selection.  Ue  express  this  formally  by  the  following  Creation  Ru*e. 


r 
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I 

R(new)5  (Vq,x)(  q t <x,N>(o)  ) 

where  N made  new  in  state  a 

■ 

The  description  of  the  "create"  operation  indicates  that  the  executor  of 
the  "create"  will  have  access  to  the  new  object  after  execution  of  the 

operation.  That  is,  if  & is  t create(x)  ],  and  N is  the  object 
created  in  state  a,  then 

<x,N>(S(o))  = (r,w,c) 

"Sensitive"  is  a predicate  applied  to  object  names,  thus  when  a new 

object  N is  "created",  we  must  decide  whether  it  is  to  be  treated  as 

sensitive  or  not.  It  is  clear  that  we  must  no_t  treat  it  as  sensitive  if  it 

ip  created  by  an  untrusty  executor  x,  for  if  N is  the  name  of  the  object 
"created",  then  w < <x,N>  after  creation.  If  N uere  treated  as  sensitive, 
but  x were  not  trusty,  then  ^problem  would  immediately  be  violated.  He 
define  our  treatment  of  created  sensitive  objects  by  the  following  Creation 
Rule. 


R(sensitive:  create)5  Sensitive(N)  o Ver  i f i ed ( a.  x) 

where  N made  new  for 

create(x)  in  state  o 


We  have  noted  that  sensitive  objects  are  not  to  be  executors.  Formally 
as  part  of  each  solution  below,  we  will  require  that  "^sensitive  hold. 


i 
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Section  5.4  Verified  Programs 

A verified  program  is  one  that  has  been  guaranteed  to  treat  sensitive 
objects  in  some  trusty  way,  that  for  the  most  part,  need  not  concern  us.  He 
will  only  be  concerned  with  those  properties  that  verified  programs  need 
satisfy  in  order  to  solve  the  problem  stated  above  - that  is,  guarantee  that 
on  I u verified  programs  can  be  used  to  alter  sensitive  objects. 

While  "Trusty"  is  a property  o * objects  (their  names,  actually), 
"Verified"  is  a property  of  the  contents  of  an  object.  We  will  write 
Ver i f i ed (c. x)  if  object  x contains  a verified  program  in  state  a.  We  build 
a bridge  between  these  two  properties  by  guaranteeing  that  trusty  executors 
contain  verified  programs. 

‘f’ver ",  f t ^ E Trusty(x)  o Ver i f ied (a.  x) 

This  requirement  will  be  part  of  each  of  the  solutions  we  uill  discuss  below. 
Since  we  will  be  proving  the  invariance  of  those  solutions,  we  note  two 
properties  of  the  "Verified"  predicate  which  follow  from  the  representation 
of  "programs"  in  the  system  described  in  appendix  A,  which  will  be  helpful  in 
proving  that  invariance. 

VRF1:  ol.  (31.  Value-part  * o2. (32. Value-par t 

o.  Ver  i f ied  (al . (31 ) = Ver  i fled  (a2./32) 

That  is,  the  static  representation  of  a program  is  contained  wholly  within 
the  Value-part  of  an  object,  so  if  the  Value-parts  of  two  objects  are  the 
same,  one  contains  a verified  program  only  if  the  other  one  does. 

We  also  note  that  execution  of  a verified  program  does  not  alter  the 
property  of  its  being  verified  (i.e.  by  changing  the  Value-part  of  the 
object  containing  the  program).  Formally 

VRF2:  Trusty(x)  a x = Executor(S)  o. 

Ver i f i ed (o. x)  o Ver i f ied ( S (a) . x) 

But  what  if  x is  not  the  executor  of  S?  Could  execution  of  an  operation 
by  some  executor  alter  the  contents  of  some  other  object  that  is  trusty?  We 
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will  arrange  each  of  the  solutions  below  so  that  such  a situation  is 
prevented. 

That  prevention  is  not  difficult  to  accomplish.  Ue  noted  above  that  an 
executor  can  only  alter  another  object  if  it  has  permission  to  write  it. 
Because  of  rule  R(neu)  (and  the  semantics  of  "call"),  when  a new  executor  is 
created  as  the  result  of  a call,  no  object,  including  the  caller,  is  given 
permission  to  write  the  new  executor.  If  we  guarantee  that  no  object 
initially  has  write  access  to  trusty  objects  (as  all  solutions  below  will  - 
via  '(’trustul  and  ^trustyZ  then  we  can  guarantee  that  if  a trusty 

object  initially  holds  a verified  program,  then  it  will  continue  to  hold  a 
verified  program  after  execution  of  any  operation,  for  its  Value-part  cannot 
be  al tered. 


Next  we  will  examimne  whether  there  are  any  actions  a trusty  executor 
might  perform  that  could  violate  ^problem*  ^ there  are  any,  then  we  must 
establish  additional  conditions  that  verified  programs  must  satisfy. 

A trusty  executor  might  grant  access  for  a sensitive  object  to  some 
object  also  accessable  to  an  untrusty  executor.  If  the  untrusty  executor 
subsequently  takes  that  access,  then  '(problem  w°uld  be  violated,  for  an 
untrusty  executor  could  gain  access  to  a sensitive  object.  This  is  depicted 
in  the  diagram  below. 
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operation,  passing  as  an  argument,  access  to  a sensitive  object  (e.g. 
cal  I (Trusty, Some-ob ject.Sensi  tl ve)  ) . 

Ue  must  now  imagine  that  some  control  mechanism  augments  the  protection 
system  provided,  for  these  violations  may  not  be  prevented  by  constraining 
the  initial  state  of  the  access  matrix  alone.  It  is  necessary  to  guarantee 
that  trusty  executors  do  not  execute  the  operations  described  above.  That 
guarantee  can  be  formalized  as  constraint  on  the  behavior  of  verified 
programs. 

Ue  assume  that  the  control  mechanism  state  can  be  so  constrained 
(remembering  from  section  3.4  that  a constraint  on  the  control  state  models 
specifications  for  the  programs  executed)  as  to  prevent  the  occurrence  of 
the  operations  noted  above  when  executed  by  objects  containing  verified 
program.  Formally,  we  expect  that  such  a constraint  can  enforce  the 

following  behavioral  constraint  in  the  base  system  (which  includes  the 
protection  mechanism): 

(markov)  ^solve^0’^  s 

Ver  i f i ed  ( o.  x)  a x » E*ecutor(&)  a Sensi  tive(|3) 
o.  6 * grantq(x,a,f3)  a 5 * call  (x, a, 0) 
a & * cal  I (x,0,a) 

That  is,  verified  programs  do  not  execute  operations  which  could  lead  to  a 
violation  of  ^problem*  The  constraint  also  guarantees  ( S •*  cal  I (x, (3, a)  ) 
that  sensitive  object  remain  passive  - are  not  called  by  trusty  objects  (our 
solutions  will  guarantee  that  no  non-trusty  executor  ever  has  the  right  to 
call  a sensitive  object,  but  trusty  executors  do,  in  particular,  when  they 
have  just  created  one). 


Section  5.5  The  First  Solution 


The  first  solution  assumes  a fixed  set  of  executors  containing  verified 
programs;  these  executors  a*-e  character ized  as  being  trusty.  Our  solution 
first  requires  that  ^sensitive  anc*  ^verif  be  sa^,s(’ied  - that  's,  there 
can  be  no  sensitive  executors,  and  each  trusty  object  must  contain  a 
verified  program,  Ue  noted  that  ^verjf  could  remain  invariant  only  if 
initially,  a trusty  executor  could  be  accessed  by  no  other  object.  Formally 
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^trustyl  a Trusty(x)  d (Vq*s,a) ( q f <a,x>(a)  ) 

Nou  we  mu9t  only  guarantee  that  only  trusty  objects  may  directly  access 
sensitive  objects. 

^direct * 

(Vq)  ( q c <x,|3>(c)  o.  Sens  i tive  (/3)  o Trusty(x)  ) 

The  solution  to  ^problem  's  conjunction  of  these  predicates. 

^solve  s ^sensitive  A ^verif  A ^trustyl  A ^direct 
<*80 1 ve* '•'solve*  enforces  problem  since 

d)  C <&  . C <0 

solve  * ^direct  - problem 

and  ^solve  ,s  '•'sol  ve"mvarian*  which  we  prove  by  showing  that 
H'soive*0*  and  '♦’solve*0^  guarantee  ve ( S (o) ) (Theorems  5-2  and 

5-3). 

1.  ^sensi  t i ve  * **  • There  is  simply  no  way  to  create  new 

sensitive  executors. 

2.  <Pver  j ^ ( S ( o) ) . If  Trusty(x),  then  by  '♦’trustyl*  x cannot  be 

written  into  by  another  executor  of  8 through  execution  of  8. 

<Pverjf  and  VRF2  guarantee  that  x cannot  alter  ver i f ied-ness  by  its 
own  action.  Finally,  no  new  trusty  objects  can  be  created. 

3.  ^trustyl  * ^ (°) ) • If  Trusty(x),  then  by  ‘♦’trustyl*  no  °ff1er 
object  has  access  to  x.  The  operations  of  Appendix  A permit  access 
to  be  granted  or  taken,  but  access  to  x cannot  be  gained  if  no 
object  initially  has  access  to  x.  Finally,  no  new  trusty  objects 
can  be  created. 

4.  ^direct  * 8 (o) ) • Suppose  0 is  sensitive  and  after  execution  of 
8,  a non-trusty  object  x gained  access  to  (3.  This  could  not  happen. 
Consider  the  following  possibilities: 


' 


[ 


Problems,  Mechanisms  & Solutions  ( 5.5  ) page  86 

a)  A trusty  executor  granted  x access  to  0.  By  ^verif*  *he 

executor  contains  a verified  program.  Prevented  by  '♦'solve* 

b)  x took  access  to  0 from  some  object  which  mu9t  be  trusty 

due  to  '♦’direct*  Prevented  by  ‘♦’trustyl’  which  guarantees  that  no 
object  can  have  read  access  to  a trusty  object,  required  by  the 
semantics  of  "take". 

c)  x created  a sensitive  object.  Prevented  by 

^sensitive:  create)*  since  * is  not  trusty. 

d)  0 was  called,  resulting  in  a new  trusty  executor  x with 

read  access  to  0.  By  '♦’direct*  *be  ca'*er  must  be  trusty. 

Prevented  by  (<Pverif  and)  S'so|Vb. 

e)  0 was  passed  as  an  argument  when  x was  created  as  ,lhe 

result  of  a call.  By  '♦’direct*  the  cal,er  must  be  trusty. 

Prevented  by  ♦'♦’verjf  and)  fs0|ve. 


Q.E.D. 


Section  5.6  The  Second  Solution 

For  our  second  solution,  we  will  not  presume  that  trusty  objects  are 
executors  only.  They  may  be  non-executors  that  can  be  "called",  resulting 
in  the  creation  of  new  trusty  executors.  This  implies  that  we  must  add  a 
new  Creation  Rule. 

R ( trusty:  call)1  Trusty(N)  iff  Trusty<0) 

where  N made  new  for 

cal  I (x,0,a)  in  state  o 

Even  when  an  object  is  not  an  executor,  its  Value-part  may  hold  the 
representation  of  a program.  In  fact,  according  to  appendix  A,  when  a 
"call"  is  made,  the  program  to  be  executed  by  the  newly  created  executor  is 
copied  from  the  Value-part  of  the  object  called.  So,  as  in  the  first 
solution,  all  trusty  objects  (whether  or  not  they  are  executors)  must 


I 

a 


k 


F 
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contain  a representation  of  a verified  program.  That  i 6 . ^verif  mu9*  b® 
satisfied. 

We  will  continue  to  require  that  only  trusty  objects  may  access  sensitive 
objects,  so  ^direct  must  be  sa t i s f i ed  as  uell. 

Finally,  though  we  permit  trusty  objects  to  be  called,  they  may  not  be 
read  from  (lest  some  other  object  take  access  to  a sensitive  object)  nr.1  be 
written  into  (lest  some  untru3ty  executor  alter  the  representation  of  the 
verified  program  in  the  Value-part). 

<Ptrusty2^°*  3 Trusty((3)  o.  r </  «x,0>(o)  a w ? «x,0>(o) 

Our  solution  is 

^solve  5 ^sensitive  A ^verif  A ^trustj2  A ^direct 

As  in  the  first  solution.  <PS0|ve  £ direct  ^problem*  Be,ow  we  Prove 
that  tgQi  ve(o,  b)  and  'f'soive^)  guarantee  <PS0|  ve  ( b (o) ) . 

1.  <Pgens|  t -(Ve  ( b (o) ) . Same  as  for  solution  1. 

2.  <Pveri f (b(o) ) . If  trusty (x)  and  b is  not  a call  operation 

which  creates  x,  then  the  proof  is  similar  to  that  for  solution  1. 

If  b is  a call  which  creates  x,  then  by  P(trustq:  call)’  *he  ot)ject 
calied  was  trusty.  By  <f>ver-|f,  that  object  contained  a a verified 
program.  Since  call  copies  the  Value-part  of  that  object  to  x,  by 
VRF1,  x contains  a verified  program  as  well.  Finally,  trusty 

objects  cannot  be  created  except  by  a call. 

3.  <<)trusty2({,(o)  * • If  trusty(0)  and  b is  not  a call  operation 
which  creates  (3,  the  proof  is  similar  to  that  of  trustyl  in  solution 
1.  If  b is  a call  which  creates  (3,  then  by  R (new)  and  the  9emantics 
of  call,  no  object  gains  read  or  write  access  to  (3.  Finally,  trusty 
objects  cannot  be  created  except  by  call. 

4.  ^direct  * Proof  same  as  for  solut  ion  1. 
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Section  5.7 The  Third  Solution 

In  the  previous  two  solutions,  we  have  required  that  only  trusty  objects 
have  direct  access  to  sensitive  objects.  In  our  third  solution,  we  will 
permit  that  access  to  be  indirect.  Ue  permit  capabilities  for  sensitive 
objects  to  be  held  in  other  objects.  These  other  objects  must  be  sensitive 
as  well,  and  must  not  be  executors  (or  callable),  since  the  programs  they 
might  execute  are  not  verified,  and  therefore,  they  might  execute  one  of  the 
operations  prevented  by  ^solve'  Instead  of  requiring  that  ^direct 
hold,  we  require 

‘(’indirect*0*  s * c «*•£><'>  3 

( Sensi  t i ve  (|3)  d.  Trusty(a)  v Sens  i t i ve  (a)  ) 

Our  third  solution,  then  is 

'(’solve  6 ‘(’sensitive  A ^verif  A ^trusty2  A ^indirect 

Before  proving  invariance,  we  note  that  since  trusty  objects  may  be 
called,  and  since  non-trusty  (though  sensitive)  objects  can  access  sensitive 
objects,  we  may  weaken  the  requirements  for  operations  that  may  not  be 
executed  by  trusty  programs.  Ue  change  '('solve  to  reclu,re  that 

(markov)  '*'so|  ve  ' l',  &)  5 

Ver i f ied (a. x)  a x = Executor(S)  a Sensitive(0) 
o.  ( 8 = grantq(x,o,(2)  a.  Trusty(cr)  v Sensi  t i ve  (a)  ) 
a ( 8 = cal  I (x, a, (3)  a Trusty(a)  ) 
a ( 8 * cal  I (x.p.a)  ) 

Now,  we  note  that 

'(’solve  ^ * ‘(’sensitive  A ‘(’indirect  * " ‘(’problem 

So,  again  we  need  prove  only  that  ‘('sol ve*0’ anc)  ‘(’solve*0*  together 
guarantee  ^so I ve ( & ( °) ) • 
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1. 

^sar.si  t i ve  ♦ ^ to) ) • 

Same  as  for  solutions  1 and 

2. 

2. 

'Pygr-  j f (S(o) ) . Same  as  for  solution  2. 

3, 

^trusty2 ^ * * 

Same  as  for  solution  2. 

A. 

<pindirect(S(o))’ 

Suppose  that  0 is  sensitive 

and  the  object  a 

which  is  neither  trusty  nor  sensitive  has  access  to  0 aftr  execution 
of  S.  This  cannot  happen.  The  possibilities  are: 

a)  A trusty  executor  granted  cr  access  to  0.  Prevented  by 

^verif  and)  ^so I ve ’ 

b)  o took  access  to  0 from  some  object,  which  by  ^indirect 

must  be  trusty  or  sensitive.  Prevented  by  ^trusty2  1 ♦ that  object 
is  trusty,  since  "t:,ke"-ing  requires  read  access.  Prevented  by 

'♦’indirect  that  object  is  sensitive. 

c)  a created  a sensitive  object.  Prevented  by 

^(sensitive:  create)  since  we  assumed  that  a is  not  trusty. 

d)  0was  called,  resulting  in  a new  executor  a which  has  read 

access  to  0.  By  ^indirect'  the  ca,,er  mus*  either  be  sensitive 
(prevented  by  ^sensitive*  °r  trusty  (prevented  by  fygpjf  and 
'♦’so I ve^ • 

e)  0 was  passed  as  an  argument  when  a was  created  as  the 

result  of  a call.  By  '♦’indirect’  the  caller  must  be  sensitive 

(prevented  by  ^sensitive*  or  trusty,  which  by  ('Pygpjf  and)  '♦'solve 
would  require  that  the  objec  : called  be  trusty  as  well.  By 
^(trusty:  call)’  a WCHJic‘  then  al^o  be  trusty  which  contradicts  the 
assumption  that  a is  neither  trusty  nor  sensitive. 


Q.E.D. 
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Section  5.8  — Conclusion 

In  this  chapter,  we  explored  solutions  to  a protection  problem  that 
required  both  initial  constraints  on  the  base  system  (including  an  access 
matrix  mechanism)  as  uell  as  behavioral  constraints  enforced  by  constraining 
the  programs  executed  by  the  control  mechanism. 

In  our  final  solution,  ue  constrained  the  protection  state  by  requiring 
that  sensitive  objects  could  not  be  executors  and  could  only  be  accessed  by 
trusty  objects  and  other  sensitive  objects.  Ue  further  guaranteed  that, 
while  trusty  objects  might  be  called,  no  object  might  have  have  read  or 
write  access  to  one. 

[ New  trusty  objects  can  only  be  created  through  "call",  and  not 
by  a "create".  Ue  might  extend  the  solution  to  permit  such 
creations,  though  only  by  trusty  executors,  who  would  then  be 
permitted  to  have  read  and  write  access  to  those  objects,  presumably 
for  the  purpose  of  making  new  trusty  programs.  The  reader  might 
note  that  access  rights  for  trusty  objects  would  further  complicate 
^solve’  *or  ue  have  to  guarantee  that  trusty  executors  would 

not  grant  these  accesses  to  non-trusty  objects  (perhaps  not  grant 
them  at  all),  and  we  would  have  to  guarantee  that  in  filling  in  the 
Value-part  of  a new  trusty  program,  the  executor  would  insure  that 
i t was  ver i f i ed  ) 

[ The  reader  might  see  how  a solution  could  be  found  to  the 
original  problem,  which  permitted  non-trusty  executors  to  read, 
though  not  write,  sensitive  objects.  We  might  designate  some  of  the 
sensitive  objects  as  "cautious"  and  permit  non-trusty  executors  to 
have  read,  but  no  other  access  to  these  objects.  Cautious  objects 
might  even  hav<=  access  rights  for  other  sensitive  objects,  although 
only  tnose  which  are  alsr  cautious,  and  only  r-rights  ) 

In  each  of  our  solutions,  we  found  we  held  to  constrain  the  behavior 
permitted  by  the  control  mechanism,  by  specifying  a property  that  must  be 
satisfied  by  verified  programs.  In  solving  a problem  such  as  the  one 
studied  here,  it  is  often  desirable  for  the  solution  to  constrain  the 
protection  state  only.  Proving  that  programs  meet  specifications  is  a task 
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one  might  in  general  like  to  avoid.  Furthermore,  unreliable  hardware  is  more 
likelg  to  violate  security  by  altering  the  program  than  by  altering  the 
protection  state,  especially  if  the  protection  state  is  coded  to  permit 
error  detection  and  correction. 

If  the  problem  studied  here  were  important  enough,,  one  might  try  to  solve 
it  by  adding  an  additional  mechanism  to  the  system  so  that  the  constraint  on 
the  control  state  might  be  eliminated. 

In  this  case,  we  might  consider  marking  each  object,  indicating  when  an 
object  is  trusty  or  sensitive.  Whenever  an  object  is  created  by  a trusty 
executor,  it  is  marked  as  sensitive.  Whenever  a trusty  object  is  called, 
the  new  executor  created  is  marked  as  trusty  as  well.  The  mechanism  might 
then  directly  guarantee  that  only  trusty  executors  may  write  into  sensitive 
objects.  Additional  reliability  may  be  obtained  if  this  mechanism  also 
prevents  those  grants  and  calls  specified  by  Vs0|ve. 

The  problem  we  have  been  studying  can  be  thought  of  as  a simplification 
of  a system  containing  multiple  types  of  sensitive  objects,  each  of  which  is 
to  be  written  only  by  trusty  executors  of  the  same  type.  These  executors 
may  be  thought  of  as  the  protected  subsystem  for  that  type.  The  mechanism 
suggested  above  is  then  seen  to  be  analogous  to  one  which  stamps  types  on 
each  object  and  permits  an  object  to  be  written  by  an  executor  only  if  the 
type  stamped  on  the  executor  matches  the  type  stamped  on  the  object.  If 
this  mechanism  also  prohibited  those  grants  and  calls  specified  by  ^solve 
as  it  would  be  altered  to  include  the  case  of  multiple  types,  then  the 
reliability  of  the  system  might  be  further  enhanced. 

The  major  point  to  be  gleaned  from  the  discussion  above  is  this:  When  a 

new  system  is  designed,  it  is  especially  important  that  we  undertake  the 
solution  of  problems  such  as  the  one  posed  in  this  chapter.  By  so  doing,  we 
determine  how  suitable  are  the  mechanisms  provided  by  the  system,  and  what 
additional  mechanisms  might  be  added  to  solve  problems  or  to  enhance 
reliability. 


amr 
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Chapter  8 - Productive  Problems 


Sec t i on  6.1 Enforcement  Problems  and  Productive  Problems 


The  behavioral  problems  described  in  the  previous  sections  have  all  been 
enforcement  problems.  They  have  represented  guarantees  about  the  continuing 
behavior  of  the  system.  For  example,  "No  untrusty  executor  must  ever  be 
able  to  write  a sensitive  object"  and  "The  robber  must  never  be  able  to 
get  any  money  by  robbing  the  bank".  That  is,  all  behaviors  permitted  in  the 
system  were  required  to  be  acceptable.  For  a produc five  problem,  we  must 
only  guarantee  that  from  any  appropriate  initial  state,  some  accepts.  ‘ e 
behavior  is  possible.  When  a productive  problem  is  represented  statically  - 


as  a property  of  the  state,  'P. 


probl  ent 


- it  is  solved  by  guaranteeing  that 


some  behavior  results  in  a state  satisfying  'Ppropienr  addition  to 

formally  defining  productive  problems,  we  will  show  how  the  methodology  of 
section  4.4  can  be  extended  to  them. 

Protection  problems  may  often  be  thought  of  as  having  tuo  parts:  How  can 

some  behavior  be  enforced  (the  enforcement  problem),  and  under  what 
conditions  may  the  solution  to  that  problem  be  imposed  on  the  system  (the 
product i ve  problem).  We  will  explore  this  situation  in  a formal  setting  in 
this  chapter. 

Finally,  in  a protection  system,  we  may  expect  that  some  executor  (or  set 
of  executors)  is  responsible  for  bringing  about  the  conditions  that 

guarantee  the  solution  of  a problem.  Other  executors  may  wish  to  thwart 
these  responsible  executors.  We  might  like  to  guarantee  that  a protection 
mechanism  permits  the  responsible  executors  to  produce  a solution  even  when 
other  executors  arbitrarily  interfere.  Ir\  this  chapter,  we  will  formally 
characterize  such  guarantees,  as  well  as  formally  specifying  solutions  to 
productive  problems. 
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Za c t i on  G.2  — The  Souffle  Example 

Consider  the  making  of  a spinach  souffle.  Our  domain  I is  what  might  be 
called  the  kitchen  state  space.  Each  element  a t 1 represents  some  state 
of  the  kitchen  - what  ingrea  ents  and  utensils  are  in  the  kitchen,  uhat's 
being  used,  uhat  is  mixed.  what  is  cooking,  etc.  The  operations  8 c A are 
state  transitions  for  this  state  space.  For  example 

&l(x,y,z):  add  x tsp  y to  bout  2 

&?(x,y,z):  mi x x at^  sper d y *or  t i me  2 

S3(x,y,z):  bake  x at  •eiperature  y for  t ime  2 

The  problem  is:  Make  ^ si  moch  souffle.  Unlike  static  problems,  we  don’t 
want  to  guarantee  that  the  system  mvariantly  contains  a spinach  souffle  (ir 
fact,  ue  rather  expec’  that  if  the  souffle  is  good  it  uon't  9tay  around  long 
at  all).  Instead,  starting  n a state  containing  the  appropriate 

ingredients,  we  want  to  transform  the  state  and  produce  one  containing  a 
spinach  souffle.  This  transformat  on  is  generally  accomplished  by  fol 'owing 
(executing)  a recipe. 

There  may  be  more  than  one  acceptable  spinach  souffle.  Ue  will  write 
^problem*0*  ' f f o is  a state  conta  ung  an  acceptable  spinach  souffle.  Ue 
call  “^problem  a static  productive  problem. 

A recipe  is  simply  some  sequence  of  cooking  operations,  that  is  a 
history,  Hrecipe. 

The  recipe  requires  trot  we  start  out  with  certain  ingredients  and 
utensils.  This  is  a constr  unt  on  the  initial  state.  There  n,ay  be  more  than 
one  acceptable  initial  state.  For  example,  it  may  not  matter  much  if  the 
initial  state  has  oleomargarine  instead  of  butter  or  a 9-inch  baking  dish 
instead  of  a 10-inch  baking  dish.  Ue  write  ^solve*0^  1 H e contains  the 
necessary  initial  utensils  and  ingredients  for  the  given  recipe. 

Given  an  appropriate  initial  state,  the  recipe  presumably  will  produce  an 
acceptable  spinach  souffle.  That  is 


^solve*0^  0 ^problem ^recipe^0* * 
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Of  course,  there  may  be  more  than  one  recipe  that  produces  a spinach 
souffle,  although  some  recipes  will  work  only  with  certain  initial  ingedients 
and  utensils  and  not  with  others.  So  we  will  write  ^sol  ve^°*  ^recipe^  1 * * 
Hrecipe  's  a reciPe  that  produces  an  acceptable  spinach  souffle  when  U9ed 
with  the  ingedients  and  utensils  supplied  by  state  o.  Formally 

*solve<®>  =>  (VH)(  Vsolve(a,H)  o -f>problem(H(ol)  ) 

The  formula  above  is  exactly  the  same  formula  as  that  for  the  solution  to 
a static  enforcement  problem,  '(’problem1  That  ls« 

<<^)sol ve’^sol ve>  er|forces  ^prop|em 
In  the  next  section  we  will  explore  this  similarity. 


Sect  ion  G.3 Producing  Solutions 


In  chapters  4 and  5.  ^so|ve  ,ias  specified  in  such  a way  that  (assuming 
that  the  system  was  initially  constrained  by  '(’solve  I execution  of  any 

I n 


behavior  satisfying  4 
the  (.revious  section 


solve 


results  in  a s:ate  satisfying  '(’probl 


enr 


solve 


is  specified  in  exactly  the  same  way. 
However,  in  solving  a behavioral  problem  we  expect  that  any  behaviors  not 
sat i s. fuinq  tSQ|ve  be  Prevented  by  the  mechanism  augmenting  the 

system;  in  solving  a productive  problem,  we  expect  that  the  mechanism 


guarantees  that  some  behavior  satisfying 
Formally  we  define  (compare  with  definition  2-19) 


'solve 


will  be  produced. 


>>  Def  G- 1 ] <4*, M>  produces  4 i f f 


(M:«P)  (a’)  d GH’>  ( Y(  rn<a’,H,>  ) ) 


that  is,  if 


so  l ve 


,M>  produces  ^golve’  then  f°r  any  initial  state 


the  mechanism  permits  the  production  of  at  least  one 
If  M is  a control  mechanism  (section  3.4), 


satisfying  ‘(’solve 
behavior  that  satisfies  '('solve1 
then  'f’fl  can  be  used  to  specify  the  program  (recipe)  that  is  to  be  executed. 


[ He  previously  showed  (theorem  3-4)  that  all  behavioral 
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constraints  enforced  by  a decision  mechanism  are  monotonic.  This  is 
not  true  of  constraints  produced  by  a decision  mechanism.  '(’solve 
may  satisfy  <o,81&2&3>  in  some  system,  but  not  <a,SlS2>. 
Certainly  this  makes  sense  for  the  spinach  souffle  example.  While 
(Sl&2&3)(o)  might  contain  an  edible  souffle,  ( SI  82) ( o)  may  not, 
especially  if  S3  is  the  operation  "bake  the  souffle".  1 

Ue  further  can  define  <<^So!we,^>  Pr°d uces  ^prob I em  *°  mean  that,  from 
any  initial  state  satisfying  ^problem1  the  mechanism  can  be  used  to 
produce  a behavior  whose  result  state  satisfies  ^problem*  ^ ^ 19  3 
control  mechanism,  may  specify  a program  whose  execution  will  result  in  a 
state  satisfying  ^problem  when  executed  in  a state  satisfying  ^spivg* 

» Del  6-21  <*s0lVe’n>  produces  «>probleni  ill 

(n:<Pso,veMo')  D GH’)  ( 'Pproblem(  TIi (H* ( o’) ) ) ) 

Thus  the  product i ve  problem  ^problem  can  be  distinguished  from  the 
enforcement  problem  'Ppr-opiem  which  is  solved  when 

("!«,solve)(°’)  3 (VH’M  <Pproblem(  rM(H’(a*))  ) ) 

At  the  end  of  the  previous  section,  we  noted  that  productive  problems 

could  be  solved  by  a pair  <<PS0| ve,^solve>  that  enforces  ^problem*  This  can 
be  explained  by  the  following  theorem  (compare  uith  theorem  4-3) 

Theorem  6-1] 

If  <<^so  I ve*  ^so  I ve>  en^orces  ^problem 
and  <<Pso|ve.M>  produces  fso/v,e 
and  M is  homomorphic 

then  ^spive.^  produces  <Pp roblen, 

Like  a static  enforcement  problem,  a static  productive  problem  ^problem 
is  shorthand  for  the  behavioral  problem  '('problem  defined  so  that 

^problem^0’  ^ s ^problem**"1*0'* 
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that  is,  a behavior  is  acceptable  (satisfying  tprob)em  ) if  the  state 
resulting  from  its  execution  satisfies  ^prob|em. 

Theorem  8-2] 

lf  <<psolve*Ysolve>  enforces  fprob,em 
and  <<psolvelf1>  Produces  tso|ve 

then  <fS0|ve.M>  produces  *problem 

The  two  theorems  above  are  analogous  to  those  of  section  4.4  and  suggest 
the  following  methodology  for  solving  productive  problems: 

1.  Find  an  initial  constraint  ^so|ve  which  eliminates  a I i states 
in  which  no  acceptable  behavior  can  be  produced. 

2.  Characterize  ( ^so/ve  ) a set  of  acceptable  behaviors.  Each 
state  satisfying  'Pgoiyg  must  be  the  initial  state  of  at  least  one 
behavior  in  the  set. 

3.  Determine  a mechanism  M that  can  produce  at  least  one  behavior 
characterized  by  '♦'solve  for  each  initial  state  satisfying  '♦’solve* 


Sect  ion  8.4  — Producing  Solutions  to  Protection  Problems 

Uhat  we  tend  to  informally  call  a protection  problem  often  turns  out  to 
be  two  problems,  one  of  them  productive.  Suppose  that  we  are  interested  in 
solving  some  enforcement  problem  '♦'prob  I em*  Ue  may  find  son'e  solution 

'♦’solve  that  solves  the  problem.  It  is  useful  to  know  how  ‘♦’solve  may 

itself  be  produced. 

For  example,  in  section  4.3  we  discussed  the  bank  robbery  problem. 

(markov)  '♦'pr0b | em ♦ o,  8)  = o.  robber . money  * S (a)  .robber,  money 

o. vaul t. money  = S (o) . vaul t . money 

in  n system  in  which 
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Sli  j_f  -*drunk  (robber)  a ->locked(vaul  t) 

( robber. money  «-  robber. money  + vault. money; 
vaul  t. money  «-  0 ) 

Ue  shouted  that  '♦'problem  could  be  enforced  by  a solution  that  required 
that  either  the  vault  be  locked  or  empty,  or  that  the  robber  be  drunk. 

Further,  ue  shoued  that  a requirement  that  the  vault  simply  be  locked  uas  an 

acceptable  (though  not  minimal)  solution. 

'Pgoive*0*  * locked(o. vaul  t) 

Another  solution  uould  simply  require  only  that  the  robber  be  drunk. 

Intuitively,  that  solution  is  not  acceptable.  The  reason  is  that  such  a 

solution  may  (presumably)  not  be  produced. 

Ue  made  the  implicit  assumption  that  someone  (e.g.  the  bank  manager) 
uanted  to  solve  the  problem  and  would  take  some  action  to  bring  about  the 
solution.  Ue  imagine  that  locking  the  vault  is  within  the  control  of  the 
bank  manager;  guaranteeing  drunk  bank  robbers  (presumably)  is  not. 

Formally  we  treat  'Pgoive  as  a Productive  problem  ^problem* 

^•'problem  sdef  ^solve 

Ue  expect  that  in  the  case  that  ^problem  character izes  the  locked  vault, 
some  other  operation,  for  example 

82;  vaul  t.  lock  ♦-  tt 

(note  we  can  now  define  the  predicate  locked  as 
locked(x)  Epef  x.lock  ) 

can  be  executed  to  satisfy  ^’’'problem*  That  's*  we  *'ncl 
^■'solve'^'solve*  enforces  <fcvprob|effl  where 

<p*solve,a)  * u 
T*solve(o-H)  = H - 82 


fj 


Problems,  Mechanisms  4 Solutions  ( 6.4  ) 


page  98 


In  any  state,  execution  of  82  (locking  of  the  vault,  presumably  by  the  bank 
manager,  Executor (82)  ■ manager)  uill  produce  ^problem* 

In  the  example  above  we  could  always  solve  '♦’’"'problem*  This  may  not 
always  be  the  case.  Possibly  the  vault  could  be  locked  only  by  someone  with 
a key.  Instead  of  a single  command  82,  we  might  have 

82(x):  i_f_  key  e <x,vault>  then  vault,  lock  *-  tt 

where  Executor ( 82 (x) ) - x 

This  introduces  the  possibility  that  no  one  may  have  the  key.  '♦’’"'problem 
can  only  be  solved  if  someone  has  the  key.  For  example,  suppose  that  x has 
the  key.  ^"‘problem  can  then  be  solved  by  <l^vsol ve*^’vsol ve>  where 

'Prtgojye^)  - key  c <x,  vaul  t>  (cr) 

^so,ve(0>  5 H = *2(x) 

Now  i f 

'♦’solve  enforces  '♦'problem 

^problem  sdef  '♦’solve 

<<^lVso I ve* '♦'’"'so I ve>  enforces  '♦’’"'problem 

then  we  say  that  <&v30| Ve  is  a context  for  the  solution  of  '♦'problem’ 
this  example,  it  is  possible  to  produce  a state  in  which  a bank  robbery 
yields  the  robber  no  money  in  any  context  in  which  x has  a key  to  the  vault. 

Section  6.5  Producing  Mechanisms 

In  section  G.3  we  showed  that  a solution  <^>vSol ve* ^'v>  cou'd  produce 
^problem  by  guaranteeing  that  for  any  state  satisfying  '♦’’"'solve'  the 
mechanism  M*  permits  execution  of  some  history  resulting  in  a state 
satisfying  '♦’’"'problem*  *n  section  6. 4,  we  showed  how  '♦’’"'problem  wight 
i self  be  a solution  to  some  enforcement  problem  '♦'problem’  That  is 

'♦’solve  enforces  '♦'problem 

Ive  3 ^'problem 


where  ’f, 
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But,  we  have  noted  that  an  enforcement  problem  may  be  solved  by  adding  a 
mechanism  M as  well.  That  is 

<<psolve'M>  enforces  tprob|em 

The  mechanisms  M and  M»v  may  be  almost,  but  not  exactly,  the  same,  and 
TMv<  are  **",e  same’  However,  represents  the  initial  constraint  on  the 

mechanism  state.  After  execution  of  some  history  (producing  <Ps0|ve  ^ • fyl* 
may  no  longer  hold;  instead  is  expected  to  hold.  Formally  we  define 
(compare  with  definition  6-2) 

>>  Def  6-3]  <<P*,M*>  produces  <lf,M>  iff 

TM*  a TM  A 

(M*j<P>v)  (o')  d (3H’)(  (H:<P)  ( H*  ( o’ ) ) ) 

Thus  if  we  want  to  guarantee  not  only  that  some  enforcement  problem 
^problem  can  s ° I v e ci , but  that  the  solution  can  be  produced  by  <<P*,Mrt>, 

then  we  must  find  a <<P,M>  such  that 

<<P,M>  enforces  tprob(em  and 
c'ftv.Mvo  produces  <<P,M> 

Sect  ion  6.6  — Local  Solutions 


Not 

everyone  in  a given  system  (e.g.  the  bank  robber)  necessarily  wants  a 
problem  to  be  solved.  He  say  that  a problem  can  be  I oca  I I u produced  by  some 
set  of  users  if  an  acceptable  behavior  can  be  produced  in  the  face  of  active 
interference  by  other  users.  Ue  will  motivate  the  formalization  of  this 
relation  by  continuing  the  discussion  of  the  bank  robbery  example  (section 
6.  A) 

Suppose  that  x has  a key,  but  x is  not  the  manager  (perhaps  x is  the 
manager’s  goat-like  dog  who  ate  the  key).  Theoretically  ^problem  (which 
requires  that  the  bank  vault  be  locked)  can  be  solved,  but  possibly  not  by 
the  executor  (in  this  case  the  bank  manager)  that  want9  it  solved.  Ue 
really  are  only  interested  in  the  solution 


Problems,  Mechanisms  & Solutions  ( S.G  ) 


page  100 


^’"solve^  e key  c cmanager , vaul  t>  (a) 

H/ivSoi  ve  to' ^ 3 H “ 82 (manager) 

which  guarantees  that  the  manager  is  the  executor  that  can  produce  the 
desired  solution. 


First  let  us  imagine  that  the  system  contains  yet  one  more  command. 

83(x,y):  j_f  evil(x)  a forgetful  (y) 

then  <y,vault>  «-  <y,vault>  - key 

where  Executor ( 83 (x, y) ) = x 

That  is,  if  y is  forgetful,  y may  forget  her  key  to  the  vault  and  the  key 
may  be  thrown  away  by  the  evil  executor  x (remember  that  the  key  does  not 
unlock,  but  only  locks,  the  vault.  Perhaps  a different  key  mau  be  required 
to  open  it).  If  the  manager  forgets  her  keys  and  the  evil  Oemono  throws 
them  away  (executes  83  (Demono, manager )) , the  vault  cannot  be  locked. 


Now  formally,  the  solution  given  above  can  still  produce  a state 
satisfying  ^’’'problem’  however,  ^*Solve  does  not  take  into  account  any 
operations  other  than  82  (manager ) . We  should  like  to  find  a solution  that 
guarantees  that  even  if  other  executors  interfere,  ^'problem  can  be 

satisfied.  For  example,  we  might  strengthen  ^*S0|Ve- 


^■'solve*0* 


key  c <manager , vaul t> (o) 

a -'forgetful  (a.  manager) 


That  is,  as  long  as  the  manager  is  not  forgetful,  it  does  not  matter  what 
other  executors  do.  Once  82(manager)  executes,  the  problem  is  solved. 


In  general,  we  might  imagine  that  if  some  consortium  of  executors  X were 
trying  to  bring  about  a state  satisfying  ^problem*  b«*  thwarted 

by  other  executors.  This  might  oe  prevented  in  two  ways.  The  approach 
taken  above  strengthens  the  initial  constraint  ^*solve  30  *bat  actions 
taken  by  other  executors  can  have  no  ill  effects.  Alternately,  the 
mechanism  M-.v  producing  T'*so|ve  might  be  so  constrained  (or  chosen)  to 
prevent  operations  of  other  executors  that  would  thwart  satisfaction  of 


problem* 


.3 


J 
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In  either  case,  we  uant  to  guarantee  that  if  <^30!  ve’^,v>  permits 
execution  of  a history  that  produces  a state  satisfying  ^''problem’  *hen 
adding  or  removing  operations  from  that  history  not  executed  by  executors  in 
X should  have  no  effect  on  the  satisfaction  of  ^problem* 

Below,  we  will  formally  define  H/X  to  mean  H with  all  operations  removed 
except  those  executed  by  X.  As  a result,  Hl/X  = H2/X  if  the  sequence  of 
operations  performed  by  executors  in  X are  the  same  for  histories  HI  and  H2. 
So,  we  can  define 

>>  Def  6-4]  <<P*,M*>  locally  produces  <<P,M>  for  X 1X1 

TM*  = TM  A 

(M*:<P*)  (o’)  o GH’MVt  H*/X  = H’/X  ])(  ( H*  ( 0* ) ) ) 

Below  we  define  H reduced  by  X.  The  similarity  in  notation  to  that  of 
definition  3-10  is  justified  by  a similarity  in  intent  ("reduction"),  as  well 
as  by  a similarity  in  the  form  of  the  definitions. 

>>  Def  6-51  H/X  (recursively  defined) 

X/X  <==  X 


(HS)/X  <== 

Let  R 

be  H/X  in 

ix 

Executor (&)  c X then 

RS  else 

R 

He  close  this 

section  by  pointing 

out  the 

likely  meaning  of  when 

<‘P*,M*>  locally  produces  <‘P,f1>  for  X in  the  case  that  M>v  is  a multiprogram 
control  mechanism  (section  3.5).  <fy|Vf  presumably  specifies  the  program 
components  of  X whose  execution  (when  the  base  state  satisfies  ^>v)  results 
in  a state  satisfying  Mj'P. 


1 


w 
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Section  S.7  Examples  of  Productive  Problems 


In  previous  chapters  we  have  shown  how  enforcemtnt  problems  correspond  to 
many  protection  and  synchronization  problems.  In  section  6.4  we  noted  that 
productive  problems  may  arise  by  considering  how  solutions  to  those 
enforcement  problems  may  be  brought  about.  In  this  section,  we  will  provide 
examples  if  productive  problems  important  in  and  of  themselves. 

First  we  consider  the  static  problem 
^problem*0*  5 w <Cohen, Sal ary> ( o) 

In  section  4.2  we  treated  this  problem  as  an  enforcement  problem  - as  a 
property  that  had  to  be  enforced.  As  an  enforcement  problem,  ^problem 
corresponds  to  the  Access  problem  - guarantee  thai  Cohen  can  never  gain 
access  to  the  Salary  file. 


Uhen  we  treat  ^problem  as  a Product j ve  problem  - as  a property  to  be 
produced,  it  corresponds  to  an  entirely  different  problem,  a Revocation 
problem  [Redell  741.  4> problem  IS  so,ved  (as  a productive  problem)  by 

determining  hew  the  system  may  be  brought  to  a state  in  which  Cohen  does  not 
have  ur  ite  access  to  the  Salary  file.  If  ^solvo'^sol  ve*  IS  a so,ution 
^problem*  and  ^solve  's  sat'sfied  by  some  state  in  which  Cohen  does  have 
write  access,  then  a corresponding  behavior  satisfying  ^Solve  mus*  have 
the  effect  of  revoking  that  access. 

Productive  problems  can  also  be  used  to  characterize  scheduling  problems. 
For  example,  to  guarantee  that  executor  x is  not  starved  [Dijkstra  72J , we 
must  show  that  some  history  can  be  produced  containing  an  operation  executed 
by  x.  Formally,  this  situation  can  be  characterized  by  the  behavioral 
productive  problem 


^problem*0’ 


6 c H a x = Executor (&) 


In  this  chapter  we  have  studied  productive  problems  - constraints  on 
behavior  that  are  to  be  produced  or  locally  produced.  Productive  problems 
and  enforcement  problems  model  a large  number  of  problems  encountered  in 
computat  ional  systems.  Even  so,  we  find  in  the  next  chapter  that  all 
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"In  this  world,  things 
factors.  He  should  look 
just  one." 


are  complicated  and  are  decided  by  many 
at  problems  from  different  aspects,  not 


Mao  Tse  Tung 


"On  the  Chungking  Negotiations" 


Section  7.1  Introduction 

Throughout  this  thesis  we  have  restricted  our  attention  to  behavioral 
problems,  those  that  can  be  characterized  as  a constraint  on  behavior  to  be 
enforced  or  produced.  He  developed  a model  in  which  those  problems  could  be 
solved  by  imposing  a constraint  and/or  adding  a mechanism  to  a given  system. 
In  this  chapter,  we  expand  our  notion  of  problem  to  include  any  problem  that 
may  be  solved  by  an  initial  constraint  and  a mechanism,  developing  a notation 
for  a problem  as  a character istic  function  of  its  solutions. 

Certain  problems  may  be  described  using  this  notation  that  cannot  be 
appropriately  described  as  behavioral  problems.  He  find  that  enforcement 
problems  cannot  be  used  to  model  information  problems,  even  though  they 
appear  able  to  at  first.  Solutions  to  enforcement  problems  are  shown  to 

satisfy  two  properties,  the  Containment  property  and  the  Join  property, 

neither  of  which  may  be  satisfied  by  solutions  to  certain  information 

prob I ems. 

He  explore  the  constraints  (boundary  conditions)  one  might  wish  to 
require  of  solutions  to  problems  and  consider  ways  of  measuring  and 

comparing  solutions.  Finally,  we  explore  the  relationships  between  maximal 
(least  restrictive)  solutions  and  those  uhich  c.'a  optimal  according  to  some 
measure,  paying  special  attention  to  a class  of  measures  we  define  as 
mono  tonic. 
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Section  7.2  Characterizing  Problems 

We  will  formally  characterize  a problem  a6  a predicate  X such  that 
X('P.M)  only  if  <<f),M>  solves  some  given  problem.  For  example,  the 
enforcement  problem  ^p-oblem  would  be  characterized  by 


X(<P,M)  a <<P,M>  enforces  ^prop|em 
The  productive  problem  'Fprobign,  is  characterized  by 
X(<P,M)  b <<P,M>  produces  ‘Pppobien, 

In  cases  where  ue  do  not  consider  adding  any  mechanism  to  a system,  we 
will  instead  write  X as  a predicate  on  an  initial  constraint  alone.  For 
examp  I e 


X(4») 


b <P  enforces  Voblem 


The  X notation  makes  it  easy  to  describe  and  compare  properties  of 
solutions  to  problems.  First,  we  develop  some  notation 


» Def  7-1]  <01  a <P2,  <P1  v <P2 

<01  A <P2  Bdef  Act.  ( ‘PI  (o)  A <02 (o)  ) 

<P1  v <02  =def  Act.  ( -PI  (ct)  v <P2 (o)  ) 

Earlier,  we  defined  (definition  2-15) 

<01  £ <02  sdef  (Vo)  ( <01  (ct)  d <02 (ct)  ) 

We  extend  that  definition  so  that 

>>  Def  7-2]  <<01,M1>  contained  in  <<P2,M2> 

<<P1,M1>  £ <<P2,  M2>  adef 

( rM1  (o’,  H’)  I (Ml : <P1 ) ( ct’)  ) g { t^Ict’.H’)  I (I12:<02)  (o’)  ) 

That  is,  <<0i,Ml>  £ <<P2,M2>  if  all  behaviors  that  can  occur  when  <<01,M1>  is 
imposed  on  a system  can  also  occur  when  <<P2,M2>  is  imposed. 
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If  '♦'problem  ,s  an  enforcement  problem,  then  any  solution  that  enforces 
^problem  ls  contained  in  any  solution  that  induces  '♦'problem*  since  the 
latter  solution  is  guaranteed  to  permit  all  behaviors  satisfying  '♦'problem' 
Formal ly 

Theorem  7-1] 

If  <<P1,M1>  enforces  fp,.ob|en, 
and  <«P2,M2>  induces  '♦'problem 

then  <<P1,M1>  £ <<P2,M2> 

which  follows  directly  from  definitions  2-18  and  2-19. 

Next  we  show  that  enforcement  problems  satisfy  two  important  properties, 
the  Containment  property  and  the  Join  property. 

Theorem  7-2]  The  Containment  Property 

<P2  £ <P1  D.  X(<P1)  o X (<P2) 

where  X('P)  = 'P  enforces  '♦'problem 

That  is,  if  'PI  enforces  '♦'problem  anc*  ^ 13  mor8  restrictive  than  <P1 
(permitting  a subset  of  the  initial  states  permitted  by  'PD,  then  <P2 
enforces  tprob|em  as  well. 

Theorem  7-31  The  Join  Property 

X («P1)  A X(<P2)  D.  X(  PI  v <P2  ) 

where  X(<P)  = <P  enforces  '♦'problem 

That  is,  if  <P  1 solves  '♦'problem  anc)  ^ solves  '♦'problem*  then  a weaker 

solution  will  solve  '♦'problem  as  we'l*  one  in  which  the  initial  states  are 
constrained  so  that  e i ther  <P1  or  P2  must  be  true. 


More  generally,  we  can  show  that 
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Theorem  7-4] 

1)  <<P2,M2>  £ <«,H1>  o.  X(<P1,M1)  o X(<P2,M2) 

2)  XOPl.M)  a X(4>2,n)  d.  X(  <P1  v <P2,  11  ) 

nhere  XCP.M)  e <<P,M>  enforces  '♦'problem 

If  ue  are  to  solve  some  problem  X uithout  adding  a mechanism,  ue  may  be 
interested  in  finding  the  maximal  (least  restrictive)  solution  to  the 
problem.  If  the  join  of  any  two  solutions  is  itself  a solution,  then  the 

maximal  solution  is  simply  the  join  of  all  of  the  solutions. 

^max  s v I I XOf)  ) 

More  generally,  if  X does  not  satisfy  the  join  property  (for  an 

example,  see  section  7.4),  then  ue  define  a maximal  solution  as  one  that 
is  no  more  restrictive  than  any  other  solution.  Formally  ue  define 

>>  Def  7-3)  'f’niax  maximally  solves  X j_f_f 

x <♦„*,>  « 

( *Kax  = * A XW)  3.  <e»ax  - f i 
Theorem  7-5) 

If  X(<P1)  a /(<P2)  d.  X(  <P1  v <P2  ) 
and  ^max  maximally  solves  X 

then  <PmaK  = v I <P  I X(<P)  ) 


Section  7.3  Constraining  and  Measuring  Solutions 

In  section  4.2  ue  noted  that  the  optimal  solution  to  an  enforcement 
problem  '♦'problem  need  not  be  one  that  induces  ^problem*  anc*  *n  *ac*  'n 
section  4.3  ue  shoued  that  if  ue  uere  not  permitted  to  add  a mechanism  in 
solving  a problem  (i.e.  only  impose  an  initial  constraint),  that  no  solution 
inducing  '♦'problem  wight  even  be  possible.  In  this  section,  ue  uill 
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consider  measures  for  solutions,  including  a cla99  of  measures,  those  that 
are  monotonic,  for  which  an  optimal  solution  does  correspond  to  one  tha* 
induces  '('problem-  More  generally,  we  will  consider  the  relationship  between 
optimal  and  maximal  (least  restrictive)  solutions. 

Even  if  we  are  not  concerned  with  optimality,  we  may  nonetheless  want  to 
eliminate  certain  solutions  from  consideration.  For  example,  any 

enforcement  problem  can  be  solved  by  "pulling  the  plug"  - that  is,  by  adding 
the  mechanism  Mnu | | which  never  executes  any  base  system  operation,  or  by 
imposing  the  constraint  ^Solve  s ff>  w^,ch  does  n(Jt  permit  the  system  to 
operate  in  any  initial  state. 

Ue  restrict  the  class  of  acceptable  solutions  by  requiring  that  solutions 
satisfy  some  constraint,  which  we  write  as  ^constraint-  ^or  e*amPle>  if  ue 
wished  to  guarantee  that  an  initial  constraint  satisfying  some  enforcement 
problem  be  satisfied  by  some  state  in  the  set  S,  we  would  define 

X(<P)  — ^constraint  ^ A ^ enf°rces  '('problem 

Hhere  Xconstraint  (<P)  e GocS)  ( V(a)  ) 

Suppose  that  we  wanted  to  guarantee  that  for  any  solution  <<P,M>  to  the 
enforcement  problem  '('problem’  *he  n,schanism  permitted  the  execution  of  at 
least  one  acceptable  behavior  from  any  state  satisfying  <P.  Ue  would  define 

X('F.M)  = Xconstrajnt  (<P,M)  a <<P,M>  enforces  fprobleni 

“here  Xconstraint  (<P,M)  s <<P,M>  produces  tpr0b|em 

As  a final  example,  suppose  that  we  want  to  guarantee  that  the  solution 
to  some  enforcement  problem  '('problem  can  '(seif  be  locally  produced  by 
some  set  of  users  X in  context  '(’context-  define 

X(<P,M)  = Xcons^rajn^  (‘P.M)  a <'P,M>  enforces  '('problem 

tfi^re  XcongtraintCP,M)  = 

GM*)  ( <‘(5COntext ’ ^,v>  loca,,y  Produces  <<P,M>  for  X ) 
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In  the  bank  robbery  problem  (section  6.4),  we  found  that  '♦'problem  cou*d 
be  enforced  both  by 

^solve^  H locked(o. vaul  t)  and 
^solve*0*  a drunk (o. robber) 

However,  we  noted  that  for  some  reasonable  context,  the  local  production 
constraint,  formalized  just  above,  eliminates  the  second  of  those  solutions. 

In  the  bank  robbery  example,  the  added  constraint  eliminated  one  possible 
solution.  In  fact,  an  added  constraint  may  eliminate  al I solutions,  except 
by  requiring  the  addition  of  a mechanism.  For  example,  suppose  we  conjoined 
with  ^constraint  above,  the  requirement  that 

'P(cr)  d.  -d ocked  ( o.  vaul  t ) a o.  vaul  t . money  x 0 

The  problem  may  still  be  solved,  but  not  without  adding  a mechanism  that 
can  provide  additional  protection  for  the  vault,  since  the  added  constraint 
requires  that  it  not  be  locked.  Ue  add  a mechanism  that  provides  merciless 
killer  dogs,  such  that  the  robber  can  only  get  to  the  vault  if  the  dogs  are 
not  guarding  it.  That  is,  in  place  of  the  command  81,  the  mechanism 
provides  81*,  defined  so  that 

T|«|  ( 81’)  (a*)  = 81  j_f  -’guarding  (o’,  vaul  t) 

X otherwi se 

where  guarding  (a’,  vaul  t)  indicates  that  the  dogs  are  guarding  the  vault  in 
state  o’.  Addition  of  this  mechanism  solves  the  bank  robbery  problem  so  long 
as  it  is  constrained  so  that 

'Pfl(o’)  s guarding  ( o’,  vaul  t) 

A likely  constraint  is  that  a solution  be  at  least  as  good  (according  to 
some  criteria)  as  a given  solution.  That  is 

^constraint  E Uorth(lPg-|Ven,Mgjven)  - W°rtb(<P,M) 

where  Uorth  is  some  measure  of  a solution’s  worth  and  "<"  is  some  partial 
order  of  those  worths. 
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Just  as  ue  wrote  X('P)  when  no  mechanism  can  be  added,  ue  write 
Uorth('P)  for  the  worth  of  a solution  that  does  not  admit  a mechanism. 

It  is  often  reasonable  to  believe  that  if  one  solution  permits  all  of  the 
behavior  permitted  by  another  solution,  it  should  be  at  least  as  worthy. 
Measures  of  worth  that  exhibit  this  property  are  monotonic. 

>>  Def  7-4]  <Uorth,<>  is  a monotonic  measure  i f f 

<<P1,M1>  c «P2,M2>  d.  UorthOPl.ni)  < Uor th(«P2,M2) 

Ue  might  value  worth  directly  in  terms  of  the  behavior  permitted, 

assuring  a monotonic  measure.  Define 

Uorthl'P.M)  = l Tn<o’,H’>  I (M:<P)  (o’)  I 

with  "5"  defined  to  be  set  inclusion  ( £ ).  Then  one  solution  is  more 
worthy  than  another  if  it  permits  more  behavior.  Vet  this  measure  may  be 
too  restrictive.  Consider  the  system 

SI:  if  a = 1 then  (31  «-  m 

82:  rf  a = 2 then  (51  «-  m 

S3:  if  a > 3 then  (32  «-  m 

The  problem 

(markov)  4/prob|em(o,  S)  s 8(a). (32  » a. (32 

can  be  solved  both  by  'PI  and  <P2  where 

<P1  (o)  s o.oc  < 1 
<P2 ( o)  a o. a < 2 

<P2  strictly  contains  ^P1 , and  therefore,  by  the  measure  above  is  more 
worthy.  However,  from  a semantic  viepoint,  it  may  be  argued  that  'PI  is  just 
as  good  as  ‘P2.  Both  solutions  have  the  effect  that  the  only  behaviors 
permitted  by  the  system  transmit  information  from  m to  (31  - no  more  and  no 
less.  It  is  clear  that  additional  research  on  valid  measures  is  necessary. 
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In  ICohen  76] , we  study  a monotonic  measure  based  on  an  Information 
transmission  formalism.  Using  that  measure,  one  solution  is  as  worthy  as 

another  if  it  permits  at  least  the  same  information  transmission  paths. 

Given  a measure  of  the  worth  of  a solution,  we  may  naturally  be 
interested  in  finding  optimal  solutions,  those  uith  maximal  worths.  Given 
some  measure  of  worth,  we  may  define  (with  respect  to  that  measure) 

>>  Def  7-5]  <’f),M>  optimally  solves  X ifj. 

War th(<P,M)  = Max  ( Worth (<P*,MiV)  I XWrt.Mrt)  I 

If  X respresents  an  enforcement  problem  ^problem*  *hen  any  solution 
that  induces  ^problem  13  optimal,  with  respect  to  any  monotonic  measure. 
Forma  I I y 

Theorem  7-6J 

If  <4>,M>  induces  tprob,ein 

then  «r<P,M>  optimally  solves  X 

with  respect  to  any  monotonic  measure 
where  Xl'P.M)  e <<P,M>  enforces  ^prob I em 

In  particular,  this  theorem  shows  that  an  optimal  solution  may  be  found 
for  anu  monotonic  enforcement  problem  (with  respect  to  a monotonic  measure). 
In  section  3.7,  we  showed  how  such  a solution  might  be  constructed. 

If  we  are  not  permitted  to  add  a mechanism  to  a system  in  order  to  solve 
an  enforcement  problem,  then  the  optimal  solution  may  not  induce  ^problem 
(see  section  4.3).  However,  for  any  problem  satisfying  the  Join  property,  a 
maximal  solution  is  an  optimal  solution  (for  a mono.tcnic  measure).  Formally 
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Theorem  7-7] 

If  X(<P1)  a X(<P2)  o X(  <P1  v <P2  ) 
and  ^max  Maximally  solves  X 

then  <Pmax  optimally  solves  X 

with  respect  to  any  monotonic  measure 

Section  7.4  Information  Problems 

In  this  section,  we  briefly  discuss  information  problems,  those  concerned 
with  guaranteeing  that  transmission  of  information  from  certain  objects  to 
other  objects  is  prevented.  Ue  will  show  that,  while  it  Is  tempting  to 
treat  information  problems  as  enforcement  problems,  solutions  to  information 
problems  do  not  satisfy  the  properties  that  must  be  satisfied  by  solutions 
to  enforcement  problems. 

Ue  could  write  (adapted  from  [Denning  751) 
a-  ( a : H)  ->(2 

to  mean  that  when  His  executed  in  state  o,  information  can  flow  from  object 
a to  object  (3. 

Suppose  that  we  wanted  to  solve  the  problem:  prevent  transmission  of 

information  from  a to  |3.  This  can  be  represented  by  the  enforcement  problem 

V°blem(0,*H)  3 -«-(a:H)->a 

that  is,  acceptable  behaviors  are  those  in  which  no  information  can  flow 
from  a to  (i.  The  problem  can  be  solved  by  V where 

<P  enforces  Voblem 

Ue  will  show  that  this  formalism  for  information  problems  is  incorrect, 
for  the  solutions  to  the  problem  of  preventing  information  transmission  from 
<x  to  (1  do  not  correspond  to  the  solutions  to  ^problem’  and  'n  fac*»  the 
solution  cannot  correspond  to  the  solutions  of  any  enforcement  problem. 
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Consider  the  system 
Sis  (3  «-  q 

S2:  j_f  m then  0 *-  a 

Transmission  of  information  from  a to  0 may  be  prevented  by  imposing  the 
constraint 

<P(cf)  s ->o.  m 

That  is,  if  m is  constrained  to  be  false,  execution  of  82  u i I I not  transmit 

information  from  a to  0.  Now  according  to  theorem  7-2,  if  an  information 

problem  is  a behavioral  problem,  a more  restrictive  solution  should  prevent 
information  transmission  from  o to  0 as  well.  Consider  the  stricter 
constraint  (the  more  restrictive  solution) 

'P(cr)  3 ->cr.m  a o.q  = o.a 

In  addition  to  requiring  that  m be  false,  <P  requires  that  the  initial  values 

o4  q and  a be  the  same.  However,  since  a and  q are  the  same,  execution  of 

81  transmits  information  about  a to  |3,  for  an  observer  of  0 can  (after  81 
has  executed)  infer  the  initial  value  of  q,  and  knowing  <P,  can  thereby  infer 
the  initial  value  of  a!  Solutions  to  information  problems  do  not  satisfy  the 
Containment  Property. 

Next  consider  the  system 

8s  0 *-  a 

A solution  that  prevents  transmission  of  information  from  a to  0 is 
'PI  (a)  3 o.a  = 23 


If  the  value  of  a is  initially  constrained  to  be  23,  no  information  can  be 
transmitted  from  a to  0.  The  amount  of  information  transmitted  from  a 


source  to  a receiver  depends  upon 
transmitted  and  the  probability  of 
Heaver  491.  If  only  one  message 


the  number  of  messages  that  can  be 
transmission  of  each  one  (Shannon  & 
can  be  sent,  no  information  can  be 
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transmitted.  By  constraining  a to  be  23,  only  one  message  can  be  sent  from 
a to  0 as  the  result  of  executing  h - the  "message"  23.  An  equally  good 
solution  is 

<P2(o)  s c.a  = 96 

However,  <P  - <P1  v <P2  is  not  a solution.  If  a may  initially  be  either 
23  or  36,  then  two  messages  can  be  sent  from  a to  |3,  and  information  can  be 
transmitted  from  a to  (3.  Therefore,  solutions  to  information  problems  do 
not  satisfy  the  Join  Property  (theorem  7-31  either. 

Solutions  to  information  problems  may  not  satisfy  the  Containment 
Property  or  the  Join  Property  because  of  the  inferential  nature  of  initial 
constraints.  If  the  value  of  an  object  is  constrained  to  be  constant,  no 
inference  can  be  made  about  the  object,  and  therefore  no  information  can  be 
transmitted  from  it.  If  the  value  of  an  object  is  constrained  to  correspond 
to  the  value  of  another  object,  an  inference  may  be  made  about  that  other 
object,  and  information  may  be  transmitted  from  it. 


In  effect,  the  initial  constraint  itself  partially  determines  which 
behaviors  are  acceptable.  This  suggests  that  a formal  theory  of  information 
transmission  must  consider  the  constraint  initially  placed  on  a system. 
[Mi  lien  761  does  note  the  importance  of  considering  constraints  in  analyzing 
information  paths  in  sequential  programs.  A formalism  for  studying 
information  transmission  in  the  presence  of  constraint  is  developed  in  [Cohen 
763  . 


This  thesis  has  developed  formalisms  for  the  concepts  - problem, 
mechanism  and  solution  - useful  for  proving  properties  about  real  systems. 
In  this  conclusion,  we  will  describe  the  important  . contributions  of  these 
formalisms  and  their  value  as  part  of  a continuing  study  of  computat ional 
systems. 

These  formalisms  are  based  upon  a simple  description  of  computational 
systems  as  a state  space  and  a set  of  discrete  indivisible  operations. 
Parallelism  is  not  modelled  directly,  but  can  be  modelled  through  the 
addition  of  a mechanism  that  interleaves  the  operations  in  appropriate  ways. 

States  are  described  as  being  wholly  comprised  of  objects  having  fixed 
unique  names.  As  a result,  it  is  possible  to  designate  objects  as  belonging 
to  some  class  (e.g.  "trusty"  or  "sensitive”  as  in  chapter  5).  The  executor 
of  (process  executing)  an  operation  corresponds  to  the  name  of  some  object. 
That  name  is  part  of  the  name  of  the  operation  and  can  be  determined 
independently  of  the  state  in  which  the  operation  executes.  These  aspects 
of  the  model  were  responsible  for  simplifying  descriptions  of  problems  and 
proofs  of  the  correctness  of  their  solutions. 


We  defined  a mechanism  so  that  it  can  be  used  uniformly  to  model  those 
things  commonly  called  "mechanisms",  including  protection  mechanisms, 

sequential  and  parallel  control  mechanisms,  synchronizat ion  mechanisms, 
levels  of  hierarchy  and  interpreters,  but  commonly  described  in  diverse 
ways.  We  categorized  mechanisms  in  terms  of  algebraic  properties, 

describing  them  as  direct,  homomorphic,  markov  and  consistent.  These 
properties  correspond  to  properties  one  might  ordinarily  consider  in  studying 
these  mechanisms.  The  latter  two  properties,  for  example,  relate  to 
concurrency. 


We  did  not  consider  properties  of  mechanisms  beyond  those  required  for 
the  purposes  of  the  thesis.  Mechanisms  do  seem  to  have  a rich  algebraic 
structure;  they  are  related  to  or  extensions  of  structures  found  in  automata 
theory,  formal  language  theory  and  category  theory.  We  also  did  not  study 
embedding  of  mechanisms  (e.g.  - the  synchronization  mechanism  embedded  in 

the  mu  1 1 iprogram  control  mechanism  - section  3.5).  These  may  be  useful 
research  topics. 
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He  described  mechanisms  in  terms  of  an  elegant  notation  that  aided  the 
description  and  development  of  a number  of  proof  techniques.  Proof 

techniques  known  to  be  useful  in  studying  one  mechanism  may  be  cast  in  a 
more  general  framework  and  applied  in  studying  a different  mechanism.  For 
example,  the  method  of  static  invariants  [Robinson  4 Holt  74]  used  in 
studying  synchronization  was  shown  here  to  be  applicable  to  protection. 

Systems  may  contain  multiple  mechanisms,  each  of  which  may  need  to  be 
constrained  in  order  to  solve  some  problem.  A uniform  mechanism  formalism 
permits  the  development  of  a formal  methodology  for  determining  those  joint 
constraints.  That  methodology  was  developed  in  section  4.4.  It  was  used  in 
chapter  5 to  find  a solution  to  a protection  problem  that  specified  both  an 
initial  constraint  on  access  rights  as  well  as  a property  that  had  to  be 
satisfied  by  the  programs  to  be  executed  by  certain  users. 

This  thesis  primarily  has  studied  a class  of  problems  we  called  behavioral 
problems,  those  that  can  be  described  as  a constraint  on  the  behavior  of  a 
system.  Using  behavioral  specifications,  both  protection  and  synchronization 
problems  can  be  described  independently  of  any  system  in  which  that  problem 
might  be  solved.  This  means  that  we  can  show,  very  natural  I y,  how  a 
protection  mechanism  might,  for  example,  be  used  to  solve  a synchronization 
i problem,  as  when  mutual  exclusion  is  enforced  by  a protection  mechanism  that 

j permits  non-sharable  capabilities  (i.e.  only  one  process  at  a time  has 

access  rights  for  some  object). 

He  showed  how  the  behavior  of  a system  could  be  constrained  by  adding  a 
mechanism  to  it  or  by  imposing  some  constraint  on  the  states  in  which  the 
system  might  initially  be  permitted  to  operate.  This  led  us  to  define  a 

solution  as  a < constraint,  mechanism  > pair.  Ue  described  a number  of 
primitive  relationships  between  < constraint,  mechanism  > pairs  and 

behavioral  constraints,  including  induce,  enforce,  produce  and  I oca  I I u 
produce.  These  descriptions  can  be  used  in  various  ways  as  part  of  a 

language  for  problem  spec i f icat ion.  For  example,  "enforce"  is  used  in 
describing  that  class  of  problems  (including  many  synchronization  and 
protection  problems)  solved  by  guaranteeing  that  execution  of  only  certain 

I acceptable  behaviors  are  to  be  permitted.  "Produce"  is  used  in  describing 

that  class  of  problems  (including  other  protection  problems  such  as  the 
revocation  problem,  and  scheduling  problems)  solved  by  guaranteeing  that  at 
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least  one  acceptable  behavior  may  always  be  executed.  The  primitives  can  be 
combined  in  various  ways  to  describe  numerous  sorts  of  problems. 


Behavioral  problem  specifications  can  be  independent  of  any  particular 
system,  and  therefore  quite  general.  As  a result,  they  may  not  be  in  a form 
well  suited  for  proving  the  correctness  of  a solution  in  some  given  system. 
When  a particular  system  is  given,  it  may  be  possible  to  convert  the 
behavioral  specification  into  a static  one  - specified  as  a property  of  the 
state  of  the  system.  It  is  often  easier  to  prove  that  some  property  of  a 
system  is  invariant  than  to  prove  that  only  acceptable  behaviors  can  be 
executed.  We  formally  demonstrated  the  validity  of  certain  conversions  from 
behavioral  to  static  specifications  and  also  developed  techniques  for  proving 
invariance.  This  technique  was  used  successfully  In  chapter  5. 


Ue  discussed  measures  for  solutions  and  characterized  a property  of 
measures  - monotonicity  - which  requires  that  the  worthiness  of  a solution 
increase  as  its  generality  increases.  Ue  did  not  consider  particular 
measures  in  great  detail.  Ue  might  have  liked  to  present  a measure  that 
would  have  formally  indicated  how  the  three  solutions  for  the  problem 
discussed  in  chapter  S differed.  Future  research  might  explore  useful 
measures  and  might  consider  ways  of  proving  optimality  of  solutions  beyond 
those  considered  in  chapter  7. 


Finally,  we  briefly  discussed  information  problems,  those  concerned  uith 
preventing  certain  information  transmission  in  computational  systems.  We 
showed  that  one  might  think  of  information  problem  as  enforcement  problems  - 
an  acceptable  behavior  being  one  in  which  illegal  information  flow  does  not 
take  place.  However,  we  showed  that  in  general,  information  problems  cannot 
be  described  in  this  way,  for  their  solutions  satisfy  neither  the  Containment 
property  nor  the  Join  property,  which  we  proved  had  to  be  satified  by 
solutions  to  enforcement  problems. 


In  [Cohen  76)  we  continue  the  study  of  information  problems,  presenting  a 
definition  of  information  transmission  based  on  ideas  taken  from  information 
theory,  and  using  those  definitions  to  formally  define  a simple  version  of 
the  Confinement  problem  and  the  Military  Security  problem.  A study  of  a 
more  complex  version  of  the  Confinement  Problem  (including 
"declassification")  is  in  progress,  including  proof  of  a solution  in  a system 
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similar  to  that  described  in  Appendix  A,  modified  to  correspond  to  the 
mechanism  provided  to  solve  Confinement  in  the  Hydra  system  (Cohen  & 
Jefferson  75] . 

Mechanisms  may  be  added  to  a system  tc  prevent  information  transmission. 
However,  (Rotenberg  73]  and  [Denning  75]  have  shown  that  mechanisms  may 
subtly  add  new  paths  for  information  transmission.  Research  in  progress 
indicates  that  the  formal  definition  of  mechanism  developed  in  this  thesis 
may  be  useful  in  understanding  how  the  addition  of  those  information  paths 
may  be  prevented.  In  particular,  strongly  consistent  mechanisms  do  not  add 
information  transmission  paths.  Since  many  of  the  implementation  levels  of 
an  operating  system  may  be  viewed  as  consistent  mechanisms,  the  mechanism 
formalism  may  be  useful  in  simplifying  proofs  of  the  information  security  of 
an  operating  system  (e.g.  [Mi  lien  76] ) . 


Finally,  while  this  thesis  has  provided  a framework  for  describing 
protection  problems,  it  has  not  discussed  any  specification  language  for 
them,  in  the  sense  that  path  expressions  [Campbell  & Habermann  753  are  a 
specif ica  'on  language  for  synchronization  problems.  Certainly,  the 
relations  induce,  enforce,  produce  and  local lu  produce  should  be  included 
(or  derivable  from  other  constructs)  in  any  such  language. 
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• Append i x A - Access  Matrix  Systems 


In  this  appendix,  ue  will  describe  Access  Matrix  systems  and  present  a 
simple  example  of  one  that  will  be  used  in  chapter  5. 

[Lampson  711  was  the  first  to  describe  protection  in  terms  of  an  access 
matrix.  A,  where  Atx.y]  contains  the  set  of  rights  x has  for  y.  For 
example,  if  r represents  the  right  to  read,  and  w represents  the  right  to 
write,  then  Cohen  will  be  allowed  to  read  the  Salary  File  only  if 
r c A [Cohen, Salary]  and  Cohen  will  be  able  to  write  the  Salary  file  only  if 
w c A (Cohen, Sa I ary] . 

Ue  will  use  the  notation  <x,y>  as  a shorthand  for  A(x,y], 


Ue  will  assume  a base  system  which  provides  four  generic  operations.  Ue 
delay  our  discussion  of  two  these,  call  and  create.  The  operation 

move (x, y, j , z, k, n) , when  executed  by  x,  moves  a portion  of  the  contents  of  z 
to  y.  The  access  matrix  mechanism  only  allows  this  operation  to  execute  if 
x has  the  right  to  read  z and  to  write  y.  The  operation  opa  (x,  y,  i , j , k) 
when  executed  by  x,  performs  some  operation  on  the  contents  of  y.  The 
mechanism  only  permits  this  operation  to  execute  if  x has  both  the  right  to 
read  and  write  y.  In  general,  an  access  matrix  mechanism  tests  a 

conjunction  of  conditions,  each  of  the  form,  q c <x,y>,  in  order  to 
determine  whether  some  operation  should  be  permitted  to  execute. 
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Since  the  mechanism  contains  a mechanism  state  (the  matrix),  there  are 
operations  that  manipulate  this  state.  For  example,  the  operation 

(1)  take,  (x,y,z)  takes  a copy  of  y’s  r-right  for  z and  gives  it  to  x. 

Thus,  taker (Cohen, Lampson, Ideas)  gives  Cohen  read  access  to  Lampson’s 

Ideas.  There  are  two  pre-requisites  for  this  operation.  Lampson  must  have 
r-rights  for  his  Ideas  and  Cohen  must  have  r-rights  for  (be  able  to  read) 
Lampson. 

The  "grant"  operation  is  the  complement  of  the  "take"  operation.  Once 
Cohen  has  taken  r-rights  for  Lampson’s  Ideas,  Cohen  can  execute 

(2)  grantr (Cohen, Library,  I deas)  which  grants  library  the  right  to  read 
(r-rights  for)  Ideas.  Subsequently,  Reader  might  execute 

(3)  taker (Reader , L i br ary , 1 deas)  to  get  r-rights  for  Ideas,  so  that 
Reader’s  attempts  to  use  Ideas  will  be  successful  (not  be  prevented  by  the 
mechan i sm) . 

In  Lampson’s  description  of  the  access  matrix,  the  matrix  was  not  square. 
The  rows  only  listed  "subjects",  those  objects  that  represented  executors. 
The  matrix  we  describe  here  is  square  so  that  passive  entities  like  Library 
can  have  the  right  to  access  objects,  if  only  so  subjects  can  "take"  these 
rights.  As  a result,  we  need  some  formal  way  to  distinguish  subjects  from 

other  objects.  He  specify  a new  right,  s-rights,  so  that  x can  be  an 

executor  only  if  sc  <x,x>. 


As  "grant"  and  "take"  share  rights  around,  "remove"  removes  rights  from 
the  matrix.  For  example,  remover (Cohen, L ibr ary,  I deas)  will  remove  Library’s 
right  to  Ideas. 

Both  remover (Cohen, L i brary,  I deas)  and  grantr (Cohen, Library, Ideas) 

require  that  Cohen  have  w-rights  for  Library.  The  reason  has  to  do  with 
information  transmission. 

Suppose  that  Cohen  has  the  right  to  write  into  an  Spy.  By  writing  into 
Spy,  Cohen  can  transmit  information  to  Spy.  Now  suppose  that  Cohen  did  not 
have  w-rights  for  Spy,  and  that  w-rights  were  unnecessary  in  order  to  grant 
some  right  to  Spy.  Cohen  can  transmit  (one  bit  of)  information  to  Spy 
depending  upon  whether  or  not  he  grants  Spy  access  to  some  object,  say 
Salary.  Spy  can  "read"  this  transmitted  information  by  attempting  to  read 
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(via  a "move")  Salary.  If  Spy  succeeds,  Cohen  has  transmitted  a "1";  If  Spy 
fails,  Cohen  has  transmitted  a "0". 

Requiring  u-rights  for  "grant"s  (and  nremove"s),  as  well  as  for  for 
"writes"  ("move"s  and  "op"s),  lets  us  consistently  treat  w-rights  as  an 
indication  of  whether  or  not  information  can  be  transmitted.  A discussion  of 
these  and  related  issues  can  be  found  in  [Cohen  & Jefferson  751. 

The  example  system  contains  a "create"  operation  that  creates  a new 
object,  and  gives  the  executor  of  the  operation  all  rights  for  that  new 
object.  To  simplify  the  formal  treatment  of  objects,  we  will  assume  that  a 
new  object  is  not  actual  lu  created.  The  system  provides  the  name  of  an 
object  not  yet  used  - one  for  which  no  other  object  has  access  rights. 

The  protection  state  'the  protection  matrix)  could  be  modelled  as  bundled 
up  in  a single  object  A.  Then  o.A[x,y]  (also  written  as  <x,y>(o)  ) would 
contain  the  set  of  rights  x had  for  y in  state  o. 

It  is  more  useful  to  model  the  protection  matrix  as  a Capability  system 
(this  system  is  in  fact,  a simplification  of  the  HYDRA  system  [Wulf  743).  We 
consider  all  of  x’s  rights  for  other  objects  to  be  part  of  x itself.  We 
divide  each  object  into  two  components,  its  "actual"  contents,  called  its 
Value-par  t and  its  set  of  rights,  called  its  C-l  ist  (for  capability  list  - 
the  set  of  rights  that  x has  for  y is  called  x’s  capabi  I i tt  for  y) . In  this 
model,  we  define 

<x,y>(o)  sqef  o.x. C-l ist  [y] 

In  the  diagram  below,  Cohen  is  a subject  with  the  right  to  read  the 
Salary  file. 
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This  treatment  of  the  protection  state  is  especially  useful  in  analyzing 
information  transmission.  Information  can  be  transmitted  to  some  object  if 
that  object  can  be  written  into.  As  we  noted  above,  x can  also  transmit 
information  to  y if  x can  change  the  rights  y has  for  other  objects.  If  y’s 

rights  for  other  objects  are  part  of  y itself,  then  manipulation  of  the 

protection  state  need  not  be  treated  as  a special  case  in  analyzing 

information  transmission. 

A thesis  by  [Rotenberg  73]  presents  a collection  of  examples  that  show 
how  subtle  (and  not  so  subtle)  manipulations  of  the  protection  state  can  be 
used  to  transmit  arbitrary  amounts  of  information.  By  representing  the 
protection  state  explicitly  in  the  manner  described  above,  these  covert 

information  channels  can  be  detected  directly  using  the  methods  of  analysis 
described  in  [Cohen  7B)  . 

Now  we  can  finally  describe  the  "call"  operation.  "Call"  is  a 
simple-minded  version  of  a re-entrant  subroutine  call  (with  no  corresponding 
return).  Programs  (subroutines)  have  two  distinct  parts. 

1.  The  code  that  will  execute.  Tn  our  system,  this  is  assumed  to 
be  in  the  Value-part  of  the  object  representing  the  program. 

2.  The  set  of  objects  every  incarnation  of  the  program  will  need 
to  access  (i.e.  own  variables  rather  than  arguments).  The  C— list 
of  the  program  object  contains  capabilities  for  these  objects. 


The  diagram  below  depicts  on  example  in  which  Cohen  calls  a Program, 


passing  along  some  Argument,  cal  I (Cohen, Program, Argument) 
dotted  lines  represent  "after  the  call"). 


(the  dotted 
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When  Program  is  called,  a new  object  N is  created.  N gets  a capability 
containing  the  same  rights  Cohen  had  to  Argument  so  that  N can  access 
Argument.  It  also  gets  r-rights  to  Program,  so  that  by  executing  "take"s, 
it  can  get  acces-,  to  any  of  the  objects  in  Program's  C-list. 

The  Value-part  of  N is  an  exact  copy  of  the  Value-part  of  Program.  This 
insures  N will  execute  the  appropriate  code  (see  section  3.5). 

In  order  to  call  Program,  Cohen  must  have  c-rights  for  Program.  In  this 
nay,  Cohen  may  be  able  to  call  a program  without  necessarily  being  able  to 
inspect  or  alter  Program’s  code  (Value-part)  or  gain  access  (via  "take")  to 
the  objects  tha*  Program  (that  is,  each  of  its  incarnat ions)  can  access. 
The  creation  of  new  object  ( incar  anat  ion)  N of  the  program  for  each  "call" 

not  only  alloir  e entrancy,  but  it  is  also  important  for  solving  a number 

of  classic  protection  problems  (e.g.  Mutual  Suspicion) 

Note  that  no  object,  including  the  caller,  gets  any  right  to  access  the 
incarnation,  N,  of  the  program.  This  means  that  (unlike  other  examples  of 
access  matrix  system,  (Lampson  71),  [Graham  & Denning  72)),  subjects  cannot 
control  each  other  directly,  but  can  only  communicate  by  transmitting 
information  through  intermediate  objects. 
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The  operations  as  provided  by  the  base  system  augmented  by  the  protection 
mechanism  are  described  below. 

A Simple  Protection  Matrix  System 


Notation 


Rights 


<x,y>  x’s  rights  for  y 

xli]  i’th  word  of  x’s  datapart 

Ixl  size  of  x’s  datapart 

Operat i ons 


r - read 
u - write 
c - call 
s - subject 


move  (x,  y,  j , z,  k,  n) : j_f_  s c <x,x>  a r t <x,z>  a w c <x,y> 

then  y[j  + i)  «-  ztk+i),  i=0,...,n-l 


opa(x,y, i , j , k ) : 
a c (add, ...  I 


i f s c <x,x>  a lr,w)  £ <x,y> 
then  yfi]  <-  a(y[j],y[kl) 


takea (x, y, z) 


jj.sc  <x,x>  atc  <x,y>  a a c <y,z> 


a c Ir.w.ci  then  <x,z>  <-  <x,z>  U (a) 


granta (x, y,  z) 
a c tr.w.cl 


jj.sc  <x,x>  a w c <x,y>  a a c <x,z> 
then  <y,z>  «-  <y,z>  U la) 


removea (x, y, z) : 
a c lr,w,c) 


j_f  s c <x,x>  a w c <x.y> 
then  <y,z>  *-  <y,z>  - la) 


create(x):  jj.  s c <x,x> 

then  let  N be  new  ob  iect  m. 
<x,N>  «-  lr,w,cl 


cal  I (x, y , z) : 


]_f  s c <x,x;  acc  <x,y> 
then  I et  N be  new  ob  iec  t J_n  ( 

N [ i ] «-  y [ i ] , i = 1 , . . . , I y I ? 
<N,  y>  ♦-  Ir  I ; 

<N,z>  «-  <x,z>  ) 


— — ■ - 


O.E.O.  13,6  contradicts  1) 
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